From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: bttanakahbk <bttanakahbk@oss.nttdata.com>
Cc: Hamid Akhtar <hamid.akhtar@gmail.com>
Cc: Pavel Stehule <pavel.stehule@gmail.com>
Cc: Peter Geoghegan <pg@bowt.ie>
Cc: Julien Rouhaud <rjuju123@gmail.com>
Cc: Tharakan, Robins <tharar@amazon.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: track_planning causing performance regression
Date: Fri, 11 Sep 2020 19:10:05 -0300
Message-ID: <20200911221005.GA6740@alvherre.pgsql> (raw)
In-Reply-To: <af5d442d-1abe-a3da-ee5f-437edc770fe7@oss.nttdata.com>
On 2020-Sep-11, Fujii Masao wrote:
> Ok, so my proposed patch degrated the performance in this case :(
> This means that replacing spinlock with lwlock in pgss is not proper
> approach for the lock contention issue on pgss...
>
> I proposed to split the spinlock for each pgss entry into two
> to reduce the lock contention, upthread. One is for planner stats,
> and the other is for executor stats. Is it worth working on
> this approach as an alternative idea? Or does anyone have any better idea?
It does seem that the excl-locked section in pgss_store is rather large.
(I admit I don't understand why would a LWLock decrease performance.)
Andres suggested in [1] to use atomics for the counters together with a
single lwlock to be used in shared mode only. I didn't quite understand
what the lwlock is *for*, but maybe you do.
[1] https://postgr.es/m/20200629231015.qlej5b3qpfe4uijo@alap3.anarazel.de
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
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: alvherre@2ndquadrant.com, masao.fujii@oss.nttdata.com, bttanakahbk@oss.nttdata.com, hamid.akhtar@gmail.com, pavel.stehule@gmail.com, pg@bowt.ie, rjuju123@gmail.com, tharar@amazon.com
Subject: Re: track_planning causing performance regression
In-Reply-To: <20200911221005.GA6740@alvherre.pgsql>
* 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