Re: Slow query: bitmap scan troubles

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: postgresql(at)foo(dot)me(dot)uk, postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Slow query: bitmap scan troubles
Date: 2012-12-05 18:05:10
Message-ID: 9022.1354730710@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> I now see where the cost is coming from. In commit 21a39de5809 (first
> appearing in 9.2) the "fudge factor" cost estimate for large indexes
> was increased by about 10 fold, which really hits this index hard.

> This was fixed in commit bf01e34b556 "Tweak genericcostestimate's
> fudge factor for index size", by changing it to use the log of the
> index size. But that commit probably won't be shipped until 9.3.

Hm. To tell you the truth, in October I'd completely forgotten about
the January patch, and was thinking that the 1/10000 cost had a lot
of history behind it. But if we never shipped it before 9.2 then of
course that idea is false. Perhaps we should backpatch the log curve
into 9.2 --- that would reduce the amount of differential between what
9.2 does and what previous branches do for large indexes.

It would definitely be interesting to know if applying bf01e34b556
helps the OP's example.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-12-05 18:07:35 Re: Dumping an Extension's Script
Previous Message Andrew Dunstan 2012-12-05 18:04:25 Re: json accessors

Browse pgsql-performance by date

  From Date Subject
Next Message Shaun Thomas 2012-12-05 18:28:23 Ubuntu 12.04 / 3.2 Kernel Bad for PostgreSQL Performance
Previous Message Claudio Freire 2012-12-05 17:43:49 Re: Slow query: bitmap scan troubles