From: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
---|---|
To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
Cc: | "Tharakan, Robins" <tharar(at)amazon(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: track_planning causing performance regression |
Date: | 2020-06-29 11:14:34 |
Message-ID: | 24e2255b-6870-406d-fc65-75f9e9feb83f@oss.nttdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2020/06/29 18:56, Fujii Masao wrote:
>
>
> On 2020/06/29 18:53, Julien Rouhaud wrote:
>> On Mon, Jun 29, 2020 at 11:38 AM Fujii Masao
>> <masao(dot)fujii(at)oss(dot)nttdata(dot)com> wrote:
>>>
>>>>> Your benchmark result seems to suggest that the cause of the problem is
>>>>> the contention of per-query spinlock in pgss_store(). Right?
>>>>> This lock contention is likely to happen when multiple sessions run
>>>>> the same queries.
>>>>>
>>>>> One idea to reduce that lock contention is to separate per-query spinlock
>>>>> into two; one is for planning, and the other is for execution. pgss_store()
>>>>> determines which lock to use based on the given "kind" argument.
>>>>> To make this idea work, also every pgss counters like shared_blks_hit
>>>>> need to be separated into two, i.e., for planning and execution.
>>>>
>>>> This can probably remove some overhead, but won't it eventually hit
>>>> the same issue when multiple connections try to plan the same query,
>>>> given the number of different queries and very low execution runtime?
>>>
>>> Yes. But maybe we can expect that the idea would improve
>>> the performance to the near same level as v12?
>>
>> A POC patch should be easy to do and see how much it solves this
>> problem. However I'm not able to reproduce the issue, and IMHO unless
>> we specifically want to be able to distinguish planner-time counters
>> from execution-time counters, I'd prefer to disable track_planning by
>> default than going this way, so that users with a sane usage won't
>> have to suffer from a memory increase.
>
> Agreed. +1 to change that default to off.
Attached patch does this.
I also add the following into the description about each *_plan_time column
in the docs. IMO this is helpful for users when they see that those columns
report zero by default and try to understand why.
(if <varname>pg_stat_statements.track_planning</varname> is enabled, otherwise zero)
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
Attachment | Content-Type | Size |
---|---|---|
disable_pgss_planning_default_v1.patch | text/plain | 3.8 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2020-06-29 11:37:43 | Re: Resetting spilled txn statistics in pg_stat_replication |
Previous Message | Dilip Kumar | 2020-06-29 10:54:13 | Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions |