Re: track_planning causing performance regression

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Ants Aasma <ants(at)cybertec(dot)at>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, "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-07-03 01:56:51
Message-ID: 20455626-bc64-724f-73f9-870a21509706@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020/07/02 1:54, Andres Freund wrote:
> Hi,
>
> On 2020-07-01 22:20:50 +0900, Fujii Masao wrote:
>> On 2020/07/01 4:03, Andres Freund wrote:
>>> Why did you add the hashing here? It seems a lot better to just add an
>>> lwlock in-place instead of the spinlock? The added size is neglegible
>>> compared to the size of pgssEntry.
>>
>> Because pgssEntry is not array entry but hashtable entry. First I was
>> thinking to assign per-process lwlock to each entry in the array at the
>> startup. But each entry is created every time new entry is required.
>> So lwlock needs to be assigned to each entry at that creation time.
>> We cannnot easily assign lwlock to all the entries at the startup.
>
> But why not just do it exactly at the place the SpinLockInit() is done
> currently?

Sorry I failed to understand your point... You mean that new lwlock should
be initialized at the place the SpinLockInit() is done currently instead of
requesting postmaster to initialize all the lwlocks required for pgss
at _PG_init()?

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2020-07-03 02:05:48 Re: Default setting for enable_hashagg_disk
Previous Message Tomas Vondra 2020-07-03 01:10:30 Re: Additional improvements to extended statistics