Re: [Proposal] More Vacuum Statistics - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [Proposal] More Vacuum Statistics
Date
Msg-id 24041.1432997241@sss.pgh.pa.us
Whole thread Raw
In response to Re: [Proposal] More Vacuum Statistics  (Andres Freund <andres@anarazel.de>)
Responses Re: [Proposal] More Vacuum Statistics  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2015-05-29 21:30:57 -0500, Jim Nasby wrote:
>> It occurs to me that there's no good reason for vacuum-derived stats to be
>> in the stats file; it's not like users run vacuum anywhere near as often as
>> other commands. It's stats could be kept in pg_class; we're already keeping
>> things like relallvisible there.

> While it might be viable to store them somewhere but the stat files, I
> don't think pg_class is a good place. Its size is not any less critical
> than the stats files. I.e. reading it sits in several rather hot paths,
> and we keep tuples from it in memory in a lot of places.

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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: [CORE] postpone next week's release
Next
From: Bruce Momjian
Date:
Subject: Re: [CORE] postpone next week's release