| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Bruce Momjian <bruce(at)momjian(dot)us> |
| Cc: | 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 03:51:38 |
| Message-ID: | 23298.1355370698@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-performance |
Bruce Momjian <bruce(at)momjian(dot)us> writes:
> On Wed, Dec 12, 2012 at 05:27:39PM -0500, Andrew Dunstan wrote:
>> 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?
> [ moved to hackers list.]
> 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.
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jan Wieck | 2012-12-13 04:03:20 | Re: PRIVATE columns |
| Previous Message | Bruce Momjian | 2012-12-13 02:48:37 | Re: [PERFORM] encouraging index-only scans |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amitabh Kant | 2012-12-13 04:08:09 | Limit & offset effect on query plans |
| Previous Message | Bruce Momjian | 2012-12-13 02:48:37 | Re: [PERFORM] encouraging index-only scans |