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

From Pavan Deolasee
Subject Re: [PERFORM] encouraging index-only scans
Date
Msg-id CABOikdPtuYq=u1rmP7gJ8gMc5Senb07SSA6wzOS0P=zx63eG1w@mail.gmail.com
Whole thread Raw
In response to Re: [PERFORM] encouraging index-only scans  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Thu, Dec 13, 2012 at 9:21 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Bruce Momjian <bruce@momjian.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.
>

Should we do that though ? i.e. scan the entire map and count the
number of bits at the end of ANALYZE, like we do at the end of VACUUM
? I recently tried to optimize that code path by not recounting at the
end of the vacuum and instead track the number of all-visible bits
while scanning them in the earlier phases on vacuum. But it turned out
that its so fast to count even a million bits that its probably not
worth doing so.

> 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.
>

+1.

Thanks,
Pavan

-- 
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee



pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: PRIVATE columns
Next
From: Josh Kupershmidt
Date:
Subject: Re: Multiple --table options for other commands