From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com>, Naoya Anzai <nao-anzai(at)xc(dot)jp(dot)nec(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Akio Iwaasa <aki-iwaasa(at)vt(dot)jp(dot)nec(dot)com>, "bench(dot)coffee(at)gmail(dot)com" <bench(dot)coffee(at)gmail(dot)com> |
Subject: | Re: [Proposal] More Vacuum Statistics |
Date: | 2015-05-30 14:47:21 |
Message-ID: | 24041.1432997241@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2015-05-30 15:45:59 | Re: [CORE] postpone next week's release |
Previous Message | Joshua D. Drake | 2015-05-30 14:11:09 | Re: [CORE] postpone next week's release |