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: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Fujii Masao <masao.fujii@oss.nttdata.com>, bttanakahbk <bttanakahbk@oss.nttdata.com>, Hamid Akhtar <hamid.akhtar@gmail.com>, Pavel Stehule <pavel.stehule@gmail.com>, Peter Geoghegan <pg@bowt.ie>, Julien Rouhaud <rjuju123@gmail.com>, "Tharakan, Robins" <tharar@amazon.com>, pgsql-hackers@postgresql.org
Date: 2020-09-11T22:32:54Z
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

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.