From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PERFORM] encouraging index-only scans |
Date: | 2012-12-13 09:40:40 |
Message-ID: | CA+U5nMJCDPtL6AkJNRpNzkwq0pEXgOoGNxj7WqOgPVaye5QGtQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-performance |
On 13 December 2012 03:51, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Yes, this does seem like a problem for upgrades from 9.2 to 9.3? We can
>> have pg_dump --binary-upgrade set these, or have ANALYZE set it. I
>> would prefer the later.
>
> ANALYZE does not set that value, and is not going to start doing so,
> because it doesn't scan enough of the table to derive a trustworthy
> value.
ISTM that ANALYZE doesn't need to scan the table to do this. The
vismap is now trustworthy and we can scan it separately on ANALYZE.
More to the point, since we run ANALYZE more frequently than we run
VACUUM, the value stored by the last VACUUM could be very stale.
> It's been clear for some time that pg_upgrade ought to do something
> about transferring the "statistics" columns in pg_class to the new
> cluster. This is just another example of why.
Agreed, but that could bring other problems as well.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Kohei KaiGai | 2012-12-13 10:04:53 | Re: [v9.3] OAT_POST_ALTER object access hooks |
Previous Message | Kohei KaiGai | 2012-12-13 09:35:47 | Re: PRIVATE columns |
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2012-12-13 13:46:45 | Re: [PERFORM] encouraging index-only scans |
Previous Message | Hari Babu | 2012-12-13 04:52:12 | Memory issue for inheritance tables. |