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: | Raw Message | Whole Thread | 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 |