Re: Statistics Import and Export - Mailing list pgsql-hackers

From Corey Huinker
Subject Re: Statistics Import and Export
Date
Msg-id CADkLM=eSnbrOPfof8JeSZriFXnqpYcyRw8-WhL5nesbkduDdUQ@mail.gmail.com
Whole thread Raw
In response to Re: Statistics Import and Export  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers

  (c) we are considering whether to use an in-place heap update for the
relation stats, so that a large restore doesn't bloat pg_class -- I'd
like feedback on this idea

I'd also like feedback, though I feel very strongly that we should do what ANALYZE does. In an upgrade situation, nearly all tables will have stats imported, which would result in an immediate doubling of pg_class - not the end of the world, but not great either.

Given the recent bugs associated with inplace updates and race conditions, if we don't want to do in-place here, we should also consider getting rid of it for ANALYZE. I briefly pondered if it would make sense to vertically partition pg_class into the stable attributes and the attributes that get modified in-place, but that list is pretty long: relpages, reltuples, relallvisible, relhasindex, reltoastrelid, relhasrules, relhastriggers, relfrozenxid, and reminmxid, 

If we don't want to do inplace updates in pg_restore_relation_stats(), then we could mitigate the bloat with a VACUUM FULL pg_class at the tail end of the upgrade if stats were enabled.
 
pg_restore_*_stats() functions. But there's a lot of overlap, so it may
be worth discussing again whether we should only have one set of
functions.

For the reason of in-place updates and error tolerance, I think they have to remain separate functions, but I'm also interested in hearing other's opinions.
 

pgsql-hackers by date:

Previous
From: Thom Brown
Date:
Subject: Re: MultiXact\SLRU buffers configuration
Next
From: Alena Rybakina
Date:
Subject: Re: Consider the number of columns in the sort cost model