Re: track_planning causing performance regression

On Tue, Jun 29, 2021 at 10:29:43AM +0800, Julien Rouhaud wrote:
> On Tue, Jun 29, 2021 at 10:09 AM Justin Pryzby <pryzby(at)telsasoft(dot)com> 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