Horton

Re: compute_query_id and pg_stat_statements

Julien Rouhaud <rjuju123@gmail.com>

View thread View on postgr.es
From: Julien Rouhaud <rjuju123@gmail.com>
To: Magnus Hagander <magnus@hagander.net>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>, Michael Paquier <michael@paquier.xyz>, Andres Freund <andres@anarazel.de>, Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Stephen Frost <sfrost@snowman.net>, Bruce Momjian <bruce@momjian.us>, Christoph Berg <myon@debian.org>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2021-05-11T09:41:06Z
Lists: pgsql-hackers 
On Tue, May 11, 2021 at 10:59:51AM +0200, Magnus Hagander wrote:
> 
> That doesn't fundamentally make it impossible, you just have to add it
> to the list of variables being copied over, wouldn't you? See
> save_backend_variables()

Yes, I agree, and that's what I meant by "explicitly handled".  The thing is
that I don't know if that's the best way to go, as it doesn't solve the "is it
actually enabled" and/or "which implementation is used".  At least the patch I
sent, although it's totally a hack, let you know if compute_query_id is enabled
or not.  I'm fine with implementing it that way, but only if there's a
consensus.

Commits

  1. Allow compute_query_id to be set to 'auto' and make it default

  2. Move pg_stat_statements query jumbling to core.