Horton

Re: track_planning causing performance regression

Justin Pryzby <pryzby@telsasoft.com>

View thread View on postgr.es
From: Justin Pryzby <pryzby@telsasoft.com>
To: Fujii Masao <masao.fujii@oss.nttdata.com>
Cc: 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: 2021-04-21T15:40:07Z
Lists: pgsql-hackers 
On Thu, Apr 22, 2021 at 12:13:17AM +0900, Fujii Masao wrote:
> On 2021/04/21 23:53, Justin Pryzby wrote:
> > Or:
> > 
> >         Enabling this parameter may incur a noticeable performance penalty,
> >         especially similar queries are executed by many concurrent connections
> >         and compete to update a small number of pg_stat_statements entries.
> 
> I prefer this. But what about using "identical" instead of "similar"
> because pg_stat_statements docs already uses "identical" in some places?

I also missed "when", again...

> >         Enabling this parameter may incur a noticeable performance penalty,
> >         especially when queries with identical structure are executed by many concurrent connections
> >         which compete to update a small number of pg_stat_statements entries.

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.