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@telsasoft.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