At Thu, 31 Mar 2022 22:12:25 -0700, Andres Freund <andres@anarazel.de> wrote in
> Hi,
>
> On 2022-03-31 20:06:07 -0700, David G. Johnston wrote:
> > Do we really think no one has taken our advice in the documentation and
> > moved their stats_temp_directory to a RAM-based file system?
>
> I'm pretty sure some have, I've seen it in the field in the past.
Oh. But no problem if no extensions enumerated upthread are not used
there. If one of them is used, the DBA saw some files generated under
pg_stat_tmp..
> > The question is whether current uses of PG_STAT_TMP_DIR can be made to use
> > the value of the GUC without them knowing or caring about the fact we
> > changed PG_STAT_TMP_DIR from a static define for pg_stat_tmp to whatever
> > the current value of stats_temp_directory is. I take it from the compiler
> > directive of #define that this isn't doable.
>
> Correct, we can't.
>
>
> > If we later want to coerce extensions (and even our own code) to use a
> > user-supplied directory we can then remove the define and give them an API
> > to use instead.
>
> FWIW, it's not quite there yet (as in, not a goal for 15), but with a bit
> further work, a number of such extensions could use the shared memory stats
> interface to store their additional stats. And they wouldn't have to care
> about where the files get stored.
pg_stat_statements has moved stored queries from shared memory to file
in comparison between memory efficiency and speed. So fast storage
could give benefit. I'm not sure the files is flushed so frequently,
though. And in the first place
But, as Andres saying, currently it *is* stored in the data directory
and no one seems complaing.
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
