Horton

Re: track_planning causing performance regression

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: Ants Aasma <ants@cybertec.at>, Julien Rouhaud <rjuju123@gmail.com>, "Tharakan, Robins" <tharar@amazon.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2020-07-01T16:54:25Z
Lists: pgsql-hackers 
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?

Greetings,

Andres Freund

Commits

  1. doc: Fix description about pg_stat_statements.track_planning.

  2. doc: Add note about possible performance overhead by enabling track_planning.

  3. Change default of pg_stat_statements.track_planning to off.