Message-ID: <46ca04f9-1e37-c862-9a28-c5dffaee412f@amazon.com>
Date: Wed, 31 Aug 2022 11:00:05 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.2.0
Subject: Re: [PATCH] Query Jumbling for CALL and SET utility statements
Content-Language: en-US
To: Andres Freund <andres@anarazel.de>, "Drouvot, Bertrand"
	<bdrouvot@amazon.com>
CC: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, "Schneider (AWS),
 Jeremy" <schnjere@amazon.com>, Peter Eisentraut
	<peter.eisentraut@enterprisedb.com>, Pavel Stehule <pavel.stehule@gmail.com>,
	Nikolay Samokhvalov <samokhvalov@gmail.com>
References: <36e5bffe-e989-194f-85c8-06e7bc88e6f7@amazon.com>
 <20220831160839.wseeotr7rckucpmv@awork3.anarazel.de>
From: Jeremy Schneider <schnjere@amazon.com>
In-Reply-To: <20220831160839.wseeotr7rckucpmv@awork3.anarazel.de>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/46ca04f9-1e37-c862-9a28-c5dffaee412f%40amazon.com>
Precedence: bulk

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