From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
cc: Alvaro Herrera <alvherre@alvh.no-ip.org>,
        Stephen Frost <sfrost@snowman.net>,
        Magnus Hagander <magnus@hagander.net>,
        Bruce Momjian <bruce@momjian.us>, Christoph Berg <myon@debian.org>,
        Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
        Fujii Masao <masao.fujii@oss.nttdata.com>,
        PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Subject: Re: compute_query_id and pg_stat_statements
In-reply-to: <20210426181408.3j6kkzpxnadpwptv@alap3.anarazel.de>
References: <2268611.1619458140@sss.pgh.pa.us>
 <20210426174331.GA19401@alvherre.pgsql>
 <20210426181408.3j6kkzpxnadpwptv@alap3.anarazel.de>
Comments: In-reply-to Andres Freund <andres@anarazel.de>
	message dated "Mon, 26 Apr 2021 11:14:08 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2295571.1619461260.1@sss.pgh.pa.us>
Date: Mon, 26 Apr 2021 14:21:00 -0400
Message-ID: <2295572.1619461260@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/2295572.1619461260%40sss.pgh.pa.us>
Precedence: bulk

Andres Freund <andres@anarazel.de> writes:
> 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.

That's sounding like a pretty sane design, actually.  Not sure about
the shared-library-name-with-fixed-function-name detail, but certainly
it seems to be useful to separate "I need a query-id" from the details
of the ID calculation.

Rather than a GUC per se for the ID provider, maybe we could have a
function hook that defaults to pointing at the in-core computation,
and then a module wanting to override that just gets into the hook.

			regards, tom lane