On Thu, Dec 13, 2012 at 03:31:06PM +0000, Peter Geoghegan wrote:
> On 13 December 2012 03:51, Tom Lane <t...@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 <br...@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
