Re: [PERFORM] encouraging index-only scans

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

In response to

Responses

Browse pgsql-hackers by date

  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

Browse pgsql-performance by date

  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.