Horton

Re: Query Jumbling for CALL and SET utility statements

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "Drouvot, Bertrand" <bertranddrouvot.pg@gmail.com>, Fujii Masao <masao.fujii@oss.nttdata.com>, Julien Rouhaud <rjuju123@gmail.com>, Jeremy Schneider <schnjere@amazon.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Pavel Stehule <pavel.stehule@gmail.com>, Andres Freund <andres@anarazel.de>, "Imseih (AWS), Sami" <simseih@amazon.com>
Date: 2022-10-07T04:13:05Z
Lists: pgsql-hackers 
On Thu, Oct 06, 2022 at 11:51:52PM -0400, Tom Lane wrote:
> I've been thinking since the beginning of this thread that there
> was no coherent, defensible rationale being offered for jumbling
> some utility statements and not others.

Yeah.  The potential performance impact of all the TransactionStmts
worries me a bit, though. 

> I wonder if the answer is to jumble them all.  We avoided that
> up to now because it would imply a ton of manual effort and
> future code maintenance ... but now that the backend/nodes/
> infrastructure is largely auto-generated, could we auto-generate
> the jumbling code?

Probably.  One part that may be tricky though is the location of the
constants we'd like to make generic, but perhaps this could be handled
by using a dedicated variable type that just maps to int?  It does not
seem like a mandatory requirement to add that everywhere as a first
step, either.
--
Michael

Commits

  1. Show values of SET statements as constants in pg_stat_statements

  2. Teach contrib/pg_stat_statements to handle multi-statement commands better.