From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)redhat(dot)com> |
Cc: | pgsql-perform <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: encouraging index-only scans |
Date: | 2012-12-12 22:12:36 |
Message-ID: | 50C90154.8060103@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
On 12/12/2012 04:32 PM, Tom Lane wrote:
> 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.
That was the problem - I didn't know this hadn't been done.
>
> 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.
Right.
Thanks for the help.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2012-12-12 22:19:57 | Re: Use gcc built-in atomic inc/dec in lock.c |
Previous Message | Mikko Tiihonen | 2012-12-12 22:11:09 | Use gcc built-in atomic inc/dec in lock.c |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2012-12-12 22:27:39 | Re: encouraging index-only scans |
Previous Message | Tom Lane | 2012-12-12 21:32:33 | Re: encouraging index-only scans |