From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
---|---|
To: | postgresql(at)foo(dot)me(dot)uk |
Cc: | postgres performance list <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Slow query: bitmap scan troubles |
Date: | 2012-12-04 15:27:57 |
Message-ID: | CAGTBQpaKOfZs+qy+S7CCPcTg7PYOrwgcQAXgWV88cQTn-BFstg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
On Tue, Dec 4, 2012 at 12:06 PM, <postgresql(at)foo(dot)me(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2012-12-04 15:38:34 | Re: PageIsAllVisible()'s trustworthiness in Hot Standby |
Previous Message | postgresql | 2012-12-04 15:21:17 | Re: Slow query: bitmap scan troubles |
From | Date | Subject | |
---|---|---|---|
Next Message | John Lister | 2012-12-04 16:30:43 | Re: Comparative tps question |
Previous Message | postgresql | 2012-12-04 15:21:17 | Re: Slow query: bitmap scan troubles |