Re: Slow query: bitmap scan troubles

Claudio Freire <klaussfreire@gmail.com>

From: Claudio Freire <klaussfreire@gmail.com>
To: postgresql@foo.me.uk
Cc: postgres performance list <pgsql-performance@postgresql.org>
Date: 2012-12-04T15:27:57Z
Lists: pgsql-hackers, pgsql-performance
On Tue, Dec 4, 2012 at 12:06 PM,  <postgresql@foo.me.uk> wrote:
> Slow version with bitmapscan enabled: http://explain.depesz.com/s/6I7
> Fast version with bitmapscan disabled: http://explain.depesz.com/s/4MWG

If you check the "fast" plan, it has a higher cost compared against
the "slow" plan.

The difference between cost estimation and actual cost of your
queries, under relatively precise row estimates, seems to suggest your
e_c_s or r_p_c aren't a reflection of your hardware's performance.

First, make sure caching isn't interfering with your results. Run each
query several times.

Then, if the difference persists, you may have to tweak
effective_cache_size first, maybe random_page_cost too, to better
match your I/O subsystem's actual performance


Commits

  1. Tweak genericcostestimate's fudge factor for index size.

  2. Tweak index costing for problems with partial indexes.