Horton

Re: track_planning causing performance regression

Fujii Masao <masao.fujii@oss.nttdata.com>

View thread View on postgr.es
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Justin Pryzby <pryzby@telsasoft.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-21T14:38:52Z
Lists: pgsql-hackers 

On 2021/04/19 23:55, Justin Pryzby wrote:
> What does "kind" mean ?  I think it means a "normalized" query or a "query
> structure".
> 
> "a fewer kinds" is wrong, so I think the docs should say "a small number of
> queries" or maybe:

Okay, I agree to update the description.

>>>>       Enabling this parameter may incur a noticeable performance penalty,
>>>>       especially similar queries are run by many concurrent connections and
>>>>       compete to update the same pg_stat_statements entry

"a small number of" is better than "similar" at the above because
"similar" sounds a bit unclear in this case?

It's better to use "entries" rather than "entry" at the above?

Regards,
  

-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

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.