Re: Raise default track_activity_query_size to 16kB (from 1kB, unchanged since 8.x)

Hi,

Thanks for putting real numbers behind this. I think there is something real
here. 1kB has felt too conservative to me for a while, though I have never
actually been blocked by it in practice. That gap is part of what I am trying
to understand: is 1kB creating a real troubleshooting gap, or is it mostly
that truncation looks alarming when you hit it?

The thing I keep coming back to is whether depesz is the right population for
picking the number. depesz usually gets used when the query and plan were
already captured somewhere else, like auto_explain, the logs, or EXPLAIN
output. So the query text was obtained somehow: either the users who submitted
to depesz had already set track_activity_query_size higher than the default,
or they pieced it together another way (auto_explain, app side, etc.).

It would also be good to understand how often not having the full SQL actually
blocked troubleshooting. In my own case log_min_duration_statement or
auto_explain usually covered it. Perhaps others have a different opinion.

On memory, you noted the local copy is palloc'd per read. Worth adding that
with monitoring sampling every second or so, that is a recurring cost rather
than one-time, and it is sized from max_connections rather than actual usage,
so you pay for every connection regardless of how many are active or how long
the queries really are. This is where a more conservative default is
the safer approach.

--
Sami Imseih
Amazon Web Services (AWS)