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 <tgl@sss.pgh.pa.us> wrote:
> Tim Uckun <timuckun@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
