On Tue, Jun 29, 2021 at 10:29:43AM +0800, Julien Rouhaud wrote:
> On Tue, Jun 29, 2021 at 10:09 AM Justin Pryzby <[email protected]> wrote:
>
> Is "identical structure" really accurate here? For instance a multi
> tenant application could rely on the search_path and only use
> unqualified relation name. So while they have queries with identical
> structure, those will generate a large number of different query_id.
We borrowed that language from the previous text:
| Plannable queries (that is, SELECT, INSERT, UPDATE, and DELETE) are combined
into a single pg_stat_statements entry whenever they have identical query
structures according to an internal hash calculation
Note that it continues to say:
|In some cases, queries with visibly different texts might get merged into a
single pg_stat_statements entry. Normally this will happen only for
semantically equivalent queries, but there is a small chance of hash collisions
causing unrelated queries to be merged into one entry. (This cannot happen for
queries belonging to different users or databases, however.)
|
|Since the queryid hash value is computed on the post-parse-analysis
representation of the queries, the opposite is also possible: queries with
identical texts might appear as separate entries, if they have different
meanings as a result of factors such as different search_path settings.
Really, I'm only trying to fix where it currently says "a fewer kinds".
It looks like I'd sent the wrong diff (git diff with a previous patch applied).
I think this is the latest proposal:
Enabling this parameter may incur a noticeable performance penalty,
- especially when a fewer kinds of queries are executed on many
- concurrent connections.
+ especially when queries with identical structure are executed by many
+ concurrent connections which compete to update a small number of
+ pg_stat_statements entries.
It could say "identical structure" or "the same queryid" or "identical queryid".
--
Justin
