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@sss.pgh.pa.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@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + It's impossible for everything to be true. +