Horton

Re: track_planning causing performance regression

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Andres Freund <andres@anarazel.de>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, 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-30T07:11:55Z
Lists: pgsql-hackers 
On Fri, Sep 11, 2020 at 03:32:54PM -0700, Andres Freund wrote:
> 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).

This discussion has stalled, and the patch proposed is incorrect, so I
have marked it as RwF in the CF app.
--
Michael

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.