From: Drouvot, Bertrand <bertranddrouvot.pg@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: Julien Rouhaud <rjuju123@gmail.com>
Cc: Jeremy Schneider <schnjere@amazon.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Imseih (AWS), Sami <simseih@amazon.com>
Subject: Re: Query Jumbling for CALL and SET utility statements
Date: Mon, 10 Oct 2022 15:04:57 +0200
Message-ID: <d391a8cf-7168-a91c-c8be-9713b2c6f6be@gmail.com> (raw)
In-Reply-To: <Yz+nUUVc3UtJtU6q@paquier.xyz>
References: <20220908112919.2ytxpkitiw6lt2u6@jrouhaud>
<a16d303f-39ad-319c-18ff-85b78b106fe1@amazon.com>
<a0d66747-3f8c-5346-5baa-61299e2cb4da@amazon.com>
<37d32e91-4a08-afaf-a3a8-fd0578e4db50@oss.nttdata.com>
<706ee610-4297-453b-f6f2-1e79161414f6@gmail.com>
<6d0d8a57-0e9c-7fcb-5072-aae544dafa5c@gmail.com>
<Yz54LU3WEYiDKS1R@paquier.xyz>
<66be1104-164f-dcb8-6c43-f03a68a139a7@gmail.com>
<Yz+f2VFqbDELGm2j@paquier.xyz>
<3088762.1665114712@sss.pgh.pa.us>
<Yz+nUUVc3UtJtU6q@paquier.xyz>
Hi,
On 10/7/22 6:13 AM, Michael Paquier wrote:
> 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?
I think that's a good idea.
>
> 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 looks to me that we'd also need to teach the perl parser which fields
per statements struct need to be jumbled (or more probably which ones to
exclude from the jumbling, for example funccall in CallStmt). Not sure
yet how to teach the perl parser, but I'll build this list first to help
decide for a right approach, unless you already have some thoughts about it?
Regards,
--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: bertranddrouvot.pg@gmail.com, michael@paquier.xyz, tgl@sss.pgh.pa.us, masao.fujii@oss.nttdata.com, rjuju123@gmail.com, schnjere@amazon.com, pgsql-hackers@lists.postgresql.org, pavel.stehule@gmail.com, andres@anarazel.de, simseih@amazon.com
Subject: Re: Query Jumbling for CALL and SET utility statements
In-Reply-To: <d391a8cf-7168-a91c-c8be-9713b2c6f6be@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox