Re: track_planning causing performance regression
От | Fujii Masao |
---|---|
Тема | Re: track_planning causing performance regression |
Дата | |
Msg-id | 20455626-bc64-724f-73f9-870a21509706@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: track_planning causing performance regression (Andres Freund <andres@anarazel.de>) |
Список | 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
В списке pgsql-hackers по дате отправления: