Re: [PERFORM] encouraging index-only scans - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: [PERFORM] encouraging index-only scans
Date
Msg-id CA+U5nMJCDPtL6AkJNRpNzkwq0pEXgOoGNxj7WqOgPVaye5QGtQ@mail.gmail.com
Whole thread Raw
In response to Re: [PERFORM] encouraging index-only scans  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PERFORM] encouraging index-only scans
List pgsql-hackers
On 13 December 2012 03:51, Tom Lane <tgl@sss.pgh.pa.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



pgsql-hackers by date:

Previous
From: Kohei KaiGai
Date:
Subject: Re: PRIVATE columns
Next
From: Kohei KaiGai
Date:
Subject: Re: [v9.3] OAT_POST_ALTER object access hooks