On Thu, Sep 17, 2009 at 5:02 PM, André Volpato <andre.volpato@xxxxxxxxxxxxxxxxxxxxx> wrote: > André Volpato escreveu: >> >> (...) >> >> (Postgres 8.3.6, Debian Linux 2.6.18-6-amd64) >> >> (...) > >> Condition 1: >> # select fat_referencia from bds_contratacao_fatura where fat_referencia >> BETWEEN 200908 AND 200908; >> Index Scan using ibds_contratacao_fatura1 on bds_contratacao_fatura >> (cost=0.00..5.64 rows=1 width=4) (actual time=0.023..79.952 rows=163689 >> loops=1) >> Index Cond: ((fat_referencia >= 200908) AND (fat_referencia <= 200908)) >> Total runtime: 110.470 ms > >> Condition 3: >> # select fat_referencia from bds_contratacao_fatura where fat_referencia = >> 200908; >> Index Scan using ibds_contratacao_fatura1 on bds_contratacao_fatura >> (cost=0.00..4745.07 rows=142940 width=4) (actual time=0.022..77.818 >> rows=163689 loops=1) >> Index Cond: (fat_referencia = 200908) >> Total runtime: 108.292 ms >> >> I expect Postgres would give me the same plan in conditions 1 and 3. > > And also the core team... > > This behaviour is 8.3 related. In 8.4, conditions 1 and 3 results in the > same plan. Hmm. I don't see anything in the release notes about it, but it's not surprising that the optimizer would be improved in a newer version. ...Robert -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance