| From: | Tom Lane <tgl(at)redhat(dot)com> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | pgsql-perform <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: encouraging index-only scans |
| Date: | 2012-12-12 21:32:33 |
| Message-ID: | 15321.1355347953@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> A client is testing a migration from 9.1 to 9.2, and has found that a
> large number of queries run much faster if they use index-only scans.
> However, the only way he has found to get such a plan is by increasing
> the seq_page_cost to insanely high levels (3.5). Is there any approved
> way to encourage such scans that's a but less violent than this?
Is the pg_class.relallvisible estimate for the table realistic? They
might need a few more VACUUM and ANALYZE cycles to get it into the
neighborhood of reality, if not.
Keep in mind also that small values of random_page_cost necessarily
decrease the apparent advantage of index-only scans. If you think 3.5
is an "insanely high" setting, I wonder whether you haven't driven those
numbers too far in the other direction to compensate for something else.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Dimitri Fontaine | 2012-12-12 21:47:23 | Re: Event Triggers: adding information |
| Previous Message | Andrew Dunstan | 2012-12-12 21:06:52 | encouraging index-only scans |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Dunstan | 2012-12-12 22:12:36 | Re: encouraging index-only scans |
| Previous Message | Andrew Dunstan | 2012-12-12 21:06:52 | encouraging index-only scans |