Re: [PERFORM] encouraging index-only scans

On Thu, Dec 13, 2012 at 03:31:06PM +0000, Peter Geoghegan wrote:
> On 13 December 2012 03:51, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > 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.
>
> I'm slightly surprised by your remarks here, because the commit
> message where the relallvisible column was added (commit
> a2822fb9337a21f98ac4ce850bb4145acf47ca27) says:
>
> "Add a column pg_class.relallvisible to remember the number of pages
> that were all-visible according to the visibility map as of the last
> VACUUM
> (or ANALYZE, or some other operations that update pg_class.relpages).
> Use relallvisible/relpages, instead of an arbitrary constant, to
> estimate how many heap page fetches can be avoided during an
> index-only scan."
>
> Have I missed some nuance?

I am looking back at this issue now and I think you are correct. The
commit you mention (Oct 7 2011) says ANALYZE updates the visibility map,
and the code matches that:

if (!inh)
vac_update_relstats(onerel,
RelationGetNumberOfBlocks(onerel),
totalrows,
--> visibilitymap_count(onerel),
hasindex,
InvalidTransactionId);

so if an index scan was not being used after an ANALYZE, it isn't a bad
allvisibile estimate but something else. This code was in PG 9.2.

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com

+ It's impossible for everything to be true. +