| From: | "Philip Scott" <pscott(at)foo(dot)me(dot)uk> |
|---|---|
| To: | "'Claudio Freire'" <klaussfreire(at)gmail(dot)com>, <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 18:31:05 |
| Message-ID: | 098101cdd24d$892524c0$9b6f6e40$@foo.me.uk |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
> 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.
Wow, so tweaking these has fixed it and then some. It now picks a slightly
different plan than the 'fast' one previously:
New super fast version with e_c_s 6GB->88Gb and r_p_c 2-> 1 (s_p_c 1->0.5):
http://explain.depesz.com/s/ECk
For reference:
> Slow version with bitmapscan enabled: http://explain.depesz.com/s/6I7
> Fast version with bitmapscan disabled: http://explain.depesz.com/s/4MWG
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Claudio Freire | 2012-12-04 18:31:50 | Re: Slow query: bitmap scan troubles |
| Previous Message | Josh Berkus | 2012-12-04 18:11:25 | Re: ALTER TABLE ... NOREWRITE option |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Claudio Freire | 2012-12-04 18:31:50 | Re: Slow query: bitmap scan troubles |
| Previous Message | postgresql | 2012-12-04 18:03:29 | Re: Slow query: bitmap scan troubles |