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
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 |
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 |