Date: Mon, 28 Jun 2021 21:45:35 -0500
From: Justin Pryzby <pryzby@telsasoft.com>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>,
	Pavel Stehule <pavel.stehule@gmail.com>,
	Peter Geoghegan <pg@bowt.ie>,
	"Tharakan, Robins" <tharar@amazon.com>,
	pgsql-hackers@postgresql.org
Subject: Re: track_planning causing performance regression
Message-ID: <20210629024535.GG21248@telsasoft.com>
References: <646e5cae-5e8b-feaa-43dc-014bf355bf08@oss.nttdata.com>
 <20210418233615.GB7256@telsasoft.com>
 <d4cb31e2-d43f-0811-8f10-cf8e2f052e5e@oss.nttdata.com>
 <20210419145545.GF7256@telsasoft.com>
 <b86e33bf-d549-db6b-f50b-3cb077807a71@oss.nttdata.com>
 <20210421145338.GT7256@telsasoft.com>
 <f2aa2d6a-3b78-0526-4ca5-8ace10eb745e@oss.nttdata.com>
 <20210421154007.GU7256@telsasoft.com>
 <20210629020918.GE21248@telsasoft.com>
 <CAOBaU_bg0OcRUykMP=_XY7tsBfjtq1NW=JeO5=p=QRg8hXAT1A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CAOBaU_bg0OcRUykMP=_XY7tsBfjtq1NW=JeO5=p=QRg8hXAT1A@mail.gmail.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
 <https://www.postgresql.org/message-id/20210629024535.GG21248%40telsasoft.com>
Precedence: bulk

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