From: Jeremy Schneider <schnjere@amazon.com>
To: Andres Freund <andres@anarazel.de>
Cc: Drouvot, Bertrand <bdrouvot@amazon.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Nikolay Samokhvalov <samokhvalov@gmail.com>
Subject: Re: [PATCH] Query Jumbling for CALL and SET utility statements
Date: Wed, 31 Aug 2022 13:05:39 -0700
Message-ID: <e43a0e02-4ef4-d510-a00a-cf39d2a9df19@amazon.com> (raw)
In-Reply-To: <20220831190604.l2luuhj3xkau7dvk@awork3.anarazel.de>
References: <36e5bffe-e989-194f-85c8-06e7bc88e6f7@amazon.com>
<20220831160839.wseeotr7rckucpmv@awork3.anarazel.de>
<46ca04f9-1e37-c862-9a28-c5dffaee412f@amazon.com>
<20220831190604.l2luuhj3xkau7dvk@awork3.anarazel.de>
On 8/31/22 12:06 PM, Andres Freund wrote:
>> Regarding SET, the compelling use case was around "application_name"
>> whose purpose is to provide a label in pg_stat_activity and on log
>> lines, which can be used to improve observability and connect queries to
>> their source in application code.
> I wasn't saying that SET shouldn't be jumbled, just that it seems more
> reasonable to track it only when track_utility is enabled, rather than doing
> so even when that's disabled. Which I do think makes sense for executing a
> prepared statement and calling a procedure, since they're really only utility
> statements by accident.
Hey Andres, sorry for misunderstanding your email!
Based on this quick test I just now ran (transcript below), I think that
PREPARE/EXECUTE is already excluded from track_utility?
I get your point about CALL, maybe it does make sense to also exclude
this. It might also be worth a small update to the doc for track_utility
about how it behaves, in this regard.
https://www.postgresql.org/docs/14/pgstatstatements.html#id-1.11.7.39.9
Example updated sentence:
> |pg_stat_statements.track_utility| controls whether <<most>> utility
commands are tracked by the module. Utility commands are all those other
than |SELECT|, |INSERT|, |UPDATE| and |DELETE| <<, but this parameter
does not disable tracking of PREPARE, EXECUTE or CALL>>. The default
value is |on|. Only superusers can change this setting.
=====
pg-14.4 rw root@db1=# set pg_stat_statements.track_utility=on;
SET
pg-14.4 rw root@db1=# select pg_stat_statements_reset();
pg_stat_statements_reset
--------------------------
(1 row)
pg-14.4 rw root@db1=# prepare test as select /* unique123 */ 1;
PREPARE
pg-14.4 rw root@db1=# execute test;
?column?
----------
1
(1 row)
pg-14.4 rw root@db1=# set application_name='test';
SET
pg-14.4 rw root@db1=# select substr(query,1,50) from pg_stat_statements;
substr
-------------------------------------------
prepare test as select /* unique123 */ $1
select pg_stat_statements_reset()
set application_name=$1
(3 rows)
=====
pg-14.4 rw root@db1=# set pg_stat_statements.track_utility=off;
SET
pg-14.4 rw root@db1=# select pg_stat_statements_reset();
pg_stat_statements_reset
--------------------------
(1 row)
pg-14.4 rw root@db1=# prepare test as select /* unique123 */ 1;
PREPARE
pg-14.4 rw root@db1=# execute test;
?column?
----------
1
(1 row)
pg-14.4 rw root@db1=# set application_name='test';
SET
pg-14.4 rw root@db1=# select substr(query,1,50) from pg_stat_statements;
substr
-------------------------------------------
prepare test as select /* unique123 */ $1
select pg_stat_statements_reset()
(2 rows)
--
Jeremy Schneider
Database Engineer
Amazon Web Services
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: schnjere@amazon.com, andres@anarazel.de, bdrouvot@amazon.com, pgsql-hackers@lists.postgresql.org, peter.eisentraut@enterprisedb.com, pavel.stehule@gmail.com, samokhvalov@gmail.com
Subject: Re: [PATCH] Query Jumbling for CALL and SET utility statements
In-Reply-To: <e43a0e02-4ef4-d510-a00a-cf39d2a9df19@amazon.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