Thank you for pointing out the stupidity. (Tom did earlier, though.)
At Mon, 21 Jan 2019 07:12:41 +0000, "Tsunakawa, Takayuki"
<[email protected]> wrote in
<0A3221C70F24FB45833433255569204D1FB6C78A@G01JPEXMBYT05>
> From: Kyotaro HORIGUCHI [mailto:[email protected]]
> > 0003: Remote GUC setting
> >
> > It is independent from the above two, and heavily arguable.
> >
> > pg_set_backend_config(pid, name, value) changes the GUC <name> on the
> > backend with <pid> to <value>.
> >
>
> Not having looked at the code yet, why did you think this is necessary?
> Can't we always collect the cache stats? Is it heavy due to some locking in
> the shared memory, or sending the stats to the stats collector?
Yeah, I had a fun making it but I don't think it can be said very
good. I must admit that it is a kind of too-much or something
stupid.
Anyway it needs to scan the whole hash to collect numbers and I
don't see how to elimite the complexity without a penalty on
regular code paths for now. I don't want do that always for the
reason.
An option is an additional PGPROC member and interface functions.
struct PGPROC
{
...
int syscahe_usage_track_interval; /* track interval, 0 to disable */
=# select syscahce_usage_track_add(<pid>, <intvl>[, <repetition>]);
=# select syscahce_usage_track_remove(2134);
Or, just provide an one-shot triggering function.
=# select syscahce_take_usage_track(<pid>);
This can use both a similar PGPROC variable or SendProcSignal()
but the former doesn't fire while idle time unless using timer.
Any thoughts?
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
