From: Jeremy Schneider <schnjere@amazon.com>
To: Andres Freund <andres@anarazel.de>
To: Drouvot, Bertrand <bdrouvot@amazon.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Cc: Schneider (AWS), Jeremy <schnjere@amazon.com>
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 11:00:05 -0700
Message-ID: <46ca04f9-1e37-c862-9a28-c5dffaee412f@amazon.com> (raw)
In-Reply-To: <20220831160839.wseeotr7rckucpmv@awork3.anarazel.de>
References: <36e5bffe-e989-194f-85c8-06e7bc88e6f7@amazon.com>
<20220831160839.wseeotr7rckucpmv@awork3.anarazel.de>
On 8/31/22 9:08 AM, Andres Freund wrote:
>
> I suspect we should carve out things like CALL, PREPARE, EXECUTE from
> track_utility - it's more or less an architectural accident that they're
> utility statements. It's a bit less clear that SET should be dealt with that
> way.
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. Nikolay's incident (on peak shopping
day for an eCommerce corp) evidently involved an application which
leveraged this, but as a result the contention on the pg_stat_statements
LWLock in exclusive mode effectively caused an outage for the retailer?
Or nearly did? My description here is based on Nikolay's public twitter
comment.
I've seen a lot of applications that make heavy use of temp tables,
where DDL would be pretty important to track as part of the regular
workload. So that probably should be added to the list alongside
prepared statements. And I'd want to spend a little more time thinking
about what other use cases might be missing. I'm hesitant about the
general idea of carving out some utility statements away from this
"track_utility" GUC.
Personally, at this point, I think pg_stat_statements is critical
infrastructure for anyone running PostgreSQL at scale. The information
it provides is indispensable. I don't think it's really defensible to
tell people that if they want to scale, then they need to fly blind on
any utility statements.
-Jeremy
--
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: <46ca04f9-1e37-c862-9a28-c5dffaee412f@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