Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans
Date
Msg-id 206d380c-adea-712d-131e-03d3b3cbf7d0@2ndquadrant.com
Whole thread Raw
In response to Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans  (Simon Riggs <simon@2ndquadrant.com>)
Responses Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans  (Julian Markwort <julian.markwort@uni-muenster.de>)
List pgsql-hackers
On 1/25/17 12:43, Simon Riggs wrote:
> On 25 January 2017 at 17:34, Julian Markwort
> <julian.markwort@uni-muenster.de> wrote:
> 
>> Analogous to this, a bad_plan is saved, when the time has been exceeded by a
>> factor greater than 1.1 .
> ...and the plan differs?
> 
> Probably best to use some stat math to calculate deviation, rather than fixed %.

Yeah, it seems to me too that this needs a bit more deeper analysis.  I
don't see offhand why a 10% deviation in execution time would be a
reasonable threshold for "good" or "bad".  A deviation approach like you
allude to would be better.

The other problem is that this measures execution time, which can vary
for reasons other than plan.  I would have expected that the cost
numbers are tracked somehow.

There is also the issue of generic vs specific plans, which this
approach might be papering over.

Needs more thought.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] PATCH: pageinspect / add page_checksum andbt_page_items(bytea)
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] [WIP]Vertical Clustered Index (columnar storeextension)