From: Justin Pryzby <pryzby@telsasoft.com>
To: Julien Rouhaud <rjuju123@gmail.com>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Peter Geoghegan <pg@bowt.ie>
Cc: Tharakan, Robins <tharar@amazon.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: track_planning causing performance regression
Date: Mon, 28 Jun 2021 21:45:35 -0500
Message-ID: <20210629024535.GG21248@telsasoft.com> (raw)
In-Reply-To: <CAOBaU_bg0OcRUykMP=_XY7tsBfjtq1NW=JeO5=p=QRg8hXAT1A@mail.gmail.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>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: pryzby@telsasoft.com, rjuju123@gmail.com, masao.fujii@oss.nttdata.com, pavel.stehule@gmail.com, pg@bowt.ie, tharar@amazon.com
Subject: Re: track_planning causing performance regression
In-Reply-To: <20210629024535.GG21248@telsasoft.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox