Re: Higher level questions around shared memory stats - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Higher level questions around shared memory stats
Date
Msg-id 20220331210416.25lvwh5bf5gbu22y@alap3.anarazel.de
Whole thread Raw
In response to Re: Higher level questions around shared memory stats  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: Higher level questions around shared memory stats  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
Hi,

On 2022-03-31 16:16:31 +0900, Kyotaro Horiguchi wrote:
> After moving to shared stats, we might want to expose the GUC variable
> itself. Then hide/remove the macro PG_STAT_TMP_DIR.  This breaks the
> extensions but it is better than keeping using PG_STAT_TMP_DIR for
> uncertain reasons. The existence of the macro can be used as the
> marker of the feature change.  This is the chance to break the (I
> think) bad practice shared among the extensions.  At least I am okay
> with that.

I don't really understand why we'd want to do it that way round? Why not just
leave PG_STAT_TMP_DIR in place, and remove the GUC? Since nothing uses the
GUC, we're not loosing anything, and we'd not break extensions unnecessarily?

Obviously there's no strong demand for pg_stat_statements et al to use the
user-configurable stats_temp_directory, given they've not done so for years
without complaints?  The code to support the configurable stats_temp_dir isn't
huge, but it's not small either.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: Commitfest closing
Next
From: "David G. Johnston"
Date:
Subject: Re: unlogged sequences