On 05/30/15 16:47, Tom Lane wrote:
Another reason why that would be a bad place is that a pg_class update forces relcache invalidation and thereby cached-plan invalidation. You don't want that for anything except (1) DDL affecting the table or (2) change in statistics that affect plan choices. It's not random chance that relallvisible is in pg_class while some other stats are in the stats collector's stuff --- the planner looks at relallvisible but not the other stuff.
We already update pg_class from autovacuum - see vac_update_relstats(). Presumably we could update the new fields in the same way, without introducing any additional cache invalidations or bloat.
But I do agree pg_class really is not the right place for this for the other reasons.
-- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
