On Mon, Apr 26, 2021 at 8:14 PM Andres Freund <and...@anarazel.de> wrote: > > Hi, > > On 2021-04-26 13:43:31 -0400, Alvaro Herrera wrote: > > I think it's straightforward, if we decouple the tri-valued enum used > > for guc.c purposes from a separate boolean that actually enables the > > feature. GUC sets the boolean to "off" initially when it sees the enum > > as "auto", and then pg_stat_statement's _PG_init modifies it during its > > own startup as needed.
That's pretty much exactly my original suggestion, yes :) > > So the user can turn the GUC off, and then pg_stat_statement does > > nothing and there is no performance drawback; or leave it "auto" and > > it'll only compute query_id if pg_stat_statement is loaded; or leave it > > on if they want the query_id for other purposes. > > I think that's the right direction. I wonder though if we shouldn't go a > bit further. Have one guc that determines the "query id provider" (NULL > or a shared library), and one GUC that configures whether query-id is > computed (never, on-demand/auto, always). For the provider GUC load the > .so and look up a function with some well known name. On Mon, Apr 26, 2021 at 8:37 PM Andres Freund <and...@anarazel.de> wrote: > I have a preference to determining the provider via GUC instead of a > hook because it is both easier to introspect and easier to configure. +1 in general. Though we could of course also have a read-only internal GUC that would show what we ended up with, and still configure it with shared_preload_libraries, or loaded in some other way. In a way it'd be cleaner to "always load modules with shared_preload_libraries", but I can certainly see the arguments in either direction.. But whichever way it's configured, having a well exposed way to know what it actually is would be important. -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/