| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
| Cc: | bttanakahbk <bttanakahbk(at)oss(dot)nttdata(dot)com>, Hamid Akhtar <hamid(dot)akhtar(at)gmail(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, "Tharakan, Robins" <tharar(at)amazon(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: track_planning causing performance regression |
| Date: | 2020-09-11 22:10:05 |
| Message-ID: | 20200911221005.GA6740@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2020-09-11 22:32:54 | Re: track_planning causing performance regression |
| Previous Message | Ranier Vilela | 2020-09-11 21:43:48 | Re: Simplified version of read_binary_file (src/backend/utils/adt/genfile.c) |