Both queries use the same row's estimation and cost is comparable. But execution time differs huge: 0.044s and 3100s. I think that the cost of backward index scan is too small.
On 1/15/11, Tom Lane <t...@sss.pgh.pa.us> wrote: > Tim Uckun <timuc...@gmail.com> writes: >> I reported this in the pgsql-general list and was instructed to send >> the analaze outputs here. > > This isn't a bug, it's just a poor choice of plan based on a bad > statistical estimate. The planner is estimating that there are 2643 > rows having domain_id = 157, when actually there are none whatsoever, > as can be seen here: > >> " -> Bitmap Index Scan on >> index_topical_urls_on_domain_id_and_consolidated_url_id >> (cost=0.00..104.63 rows=2643 width=0) (actual time=44.629..44.629 >> rows=0 loops=1)" >> " Index Cond: (domain_id = 157)" > > Possibly the table's never been ANALYZEd ... do you have autovacuum > enabled? If it has been analyzed reasonably recently, then it might be > necessary to crank up the statistics target to get a better estimate. > It's difficult to give detailed advice when you haven't mentioned what > PG version you're running. > > regards, tom lane > > -- > Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-bugs > -- Sent from my mobile device ------------ pasman -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
