Re: Is it useful to record whether plans are generic or custom?

From: torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>
To: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, ikedamsh(at)oss(dot)nttdata(dot)com, atorik(at)gmail(dot)com, legrand_legrand(at)hotmail(dot)com, tatsuro(dot)yamada(dot)tf(at)nttcom(dot)co(dot)jp
Subject: Re: Is it useful to record whether plans are generic or custom?
Date: 2020-07-31 09:47:48
Message-ID: 1afd936428977fd4931887aac269fc7b@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 Content-Type Size
0002-POC-add-plan-type-to-pgss.patch text/x-diff 8.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ajin Cherian 2020-07-31 09:52:27 Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions
Previous Message Michael Paquier 2020-07-31 09:43:54 Re: windows config.pl question