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: Peter Geoghegan <pg@bowt.ie>
Cc: Julien Rouhaud <rjuju123@gmail.com>, "Tharakan, Robins" <tharar@amazon.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2020-06-30T13:40:40Z
Lists: pgsql-hackers 

On 2020/06/30 7:29, Peter Geoghegan wrote:
> On Mon, Jun 29, 2020 at 3:23 PM Peter Geoghegan <pg@bowt.ie> wrote:
>> +1 -- this regression seems unacceptable to me.
> 
> I added an open item to track this.

Thanks!
I'm thinking to change the default value of track_planning to off for v13.

Ants and Andres suggested to replace the spinlock used in pgss_store() with
LWLock. I agreed with them and posted the POC patch doing that. But I think
the patch is an item for v14. The patch may address the reported performance
issue, but may cause other performance issues in other workloads. We would
need to measure how the patch affects the performance in various workloads.
It seems too late to do that at this stage of v13. Thought?

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.