Re: Is it useful to record whether plans are generic or custom? - Mailing list pgsql-hackers

From torikoshia
Subject Re: Is it useful to record whether plans are generic or custom?
Date
Msg-id 1afd936428977fd4931887aac269fc7b@oss.nttdata.com
Whole thread Raw
In response to Re: Is it useful to record whether plans are generic or custom?  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Responses Re: Is it useful to record whether plans are generic or custom?
List pgsql-hackers
On 2020-07-30 14:31, Fujii Masao wrote:
> On 2020/07/22 16:49, torikoshia wrote:
>> On 2020-07-20 13:57, torikoshia wrote:
>> 
>>> As I proposed earlier in this thread, I'm now trying to add 
>>> information
>>> about generic/cudstom plan to pg_stat_statements.
>>> I'll share the idea and the poc patch soon.
>> 
>> Attached a poc patch.
> 
> Thanks for the POC patch!
> 
> With the patch, when I ran "CREATE EXTENSION pg_stat_statements",
> I got the following error.
> 
> ERROR:  function pg_stat_statements_reset(oid, oid, bigint) does not 
> exist

Oops, sorry about that.
I just fixed it there for now.

>> 
>> Main purpose is to decide (1) the user interface and (2) the
>> way to get the plan type from pg_stat_statements.
>> 
>> (1) the user interface
>> I added a new boolean column 'generic_plan' to both
>> pg_stat_statements view and the member of the hash key of
>> pg_stat_statements.
>> 
>> This is because as Legrand pointed out the feature seems
>> useful under the condition of differentiating all the
>> counters for a queryid using a generic plan and the one
>> using a custom one.
> 
> I don't like this because this may double the number of entries in 
> pgss.
> Which means that the number of entries can more easily reach
> pg_stat_statements.max and some entries will be discarded.
> 
> 
>> I thought it might be preferable to make a GUC to enable
>> or disable this feature, but changing the hash key makes
>> it harder.
> 
> What happens if the server was running with this option enabled and 
> then
> restarted with the option disabled? Firstly two entries for the same 
> query
> were stored in pgss because the option was enabled. But when it's 
> disabled
> and the server is restarted, those two entries should be merged into 
> one
> at the startup of server? If so, that's problematic because it may take
> a long time.
> 
> Therefore I think that it's better and simple to just expose the number 
> of
> times generic/custom plan was chosen for each query.
> 
> Regards,

Regards,

--
Atsushi Torikoshi
NTT DATA CORPORATION
Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: windows config.pl question
Next
From: Ajin Cherian
Date:
Subject: Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions