Re: track_planning causing performance regression

From: Andres Freund <andres(at)anarazel(dot)de>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, 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:32:54
Message-ID: 20200911223254.isq7veutwxat4n2w@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2020-09-11 19:10:05 -0300, Alvaro Herrera wrote:
> 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

Just to be clear - I am saying that in the first iteration I would just
straight up replace the spinlock with an lwlock, i.e. having many
lwlocks.

The piece about a single shared lwlocks is/was about protecting the set
of entries that are currently in-memory - which can't easily be
implemented just using atomics (at least without the risk of increasing
the counters of an entry since replaced with another query).

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2020-09-12 00:13:01 Re: 回复:how to create index concurrently on partitioned table
Previous Message Alvaro Herrera 2020-09-11 22:10:05 Re: track_planning causing performance regression