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:27:39 |
Message-ID: | 50C904DB.9090305@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
On 12/12/2012 05:12 PM, Andrew Dunstan wrote:
>
> 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.
>
Actually, the table had been analysed but not vacuumed, so this kinda
begs the question what will happen to this value on pg_upgrade? Will
people's queries suddenly get slower until autovacuum kicks in on the table?
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2012-12-12 22:52:17 | Re: Enabling Checksums |
Previous Message | Peter Geoghegan | 2012-12-12 22:19:57 | Re: Use gcc built-in atomic inc/dec in lock.c |
From | Date | Subject | |
---|---|---|---|
Next Message | Craig Ringer | 2012-12-12 23:26:36 | Re: Do I have a hardware or a software problem? |
Previous Message | Andrew Dunstan | 2012-12-12 22:12:36 | Re: encouraging index-only scans |