From: | torikoshia <torikoshia(at)oss(dot)nttdata(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
Cc: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, ikedamsh(at)oss(dot)nttdata(dot)com, atorik(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org, 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-14 12:24:25 |
Message-ID: | 0d9a44529fd2398f0f2fd3bb90268251@oss.nttdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2020-07-10 10:49, torikoshia wrote:
> On 2020-07-08 16:41, Fujii Masao wrote:
>> On 2020/07/08 10:14, torikoshia wrote:
>>> On 2020-07-06 22:16, Fujii Masao wrote:
>>>> On 2020/06/11 14:59, torikoshia wrote:
>>>>> On 2020-06-10 18:00, Kyotaro Horiguchi wrote:
>>>>>
>>>>>>
>>>>>> + TupleDescInitEntry(tupdesc, (AttrNumber) 8, "last_plan",
>>>>>>
>>>>>> This could be a problem if we showed the last plan in this view.
>>>>>> I
>>>>>> think "last_plan_type" would be better.
>>>>>>
>>>>>> + if (prep_stmt->plansource->last_plan_type ==
>>>>>> PLAN_CACHE_TYPE_CUSTOM)
>>>>>> + values[7] = CStringGetTextDatum("custom");
>>>>>> + else if (prep_stmt->plansource->last_plan_type ==
>>>>>> PLAN_CACHE_TYPE_GENERIC)
>>>>>> + values[7] = CStringGetTextDatum("generic");
>>>>>> + else
>>>>>> + nulls[7] = true;
>>>>>>
>>>>>> Using swith-case prevents future additional type (if any) from
>>>>>> being
>>>>>> unhandled. I think we are recommending that as a convension.
>>>>>
>>>>> Thanks for your reviewing!
>>>>>
>>>>> I've attached a patch that reflects your comments.
>>>>
>>>> Thanks for the patch! Here are the comments.
>>>
>>> Thanks for your review!
>>>
>>>> + Number of times generic plan was choosen
>>>> + Number of times custom plan was choosen
>>>>
>>>> Typo: "choosen" should be "chosen"?
>>>
>>> Thanks, fixed them.
>>>
>>>> + <entry role="catalog_table_entry"><para
>>>> role="column_definition">
>>>> + <structfield>last_plan_type</structfield> <type>text</type>
>>>> + </para>
>>>> + <para>
>>>> + Tells the last plan type was generic or custom. If the
>>>> prepared
>>>> + statement has not executed yet, this field is null
>>>> + </para></entry>
>>>>
>>>> Could you tell me how this information is expected to be used?
>>>> I think that generic_plans and custom_plans are useful when
>>>> investigating
>>>> the cause of performance drop by cached plan mode. But I failed to
>>>> get
>>>> how much useful last_plan_type is.
>>>
>>> This may be an exceptional case, but I once had a case needed
>>> to ensure whether generic or custom plan was chosen for specific
>>> queries in a development environment.
>>
>> In your case, probably you had to ensure that the last multiple (or
>> every)
>> executions chose generic or custom plan? If yes, I'm afraid that
>> displaying
>> only the last plan mode is not enough for your case. No?
>> So it seems better to check generic_plans or custom_plans columns in
>> the
>> view rather than last_plan_type even in your case. Thought?
>
> Yeah, I now feel last_plan is not so necessary and only the numbers of
> generic/custom plan is enough.
>
> If there are no objections, I'm going to remove this column and related
> codes.
As mentioned, I removed last_plan column.
Regards,
--
Atsushi Torikoshi
NTT DATA CORPORATION
Attachment | Content-Type | Size |
---|---|---|
0007-Expose-counters-of-plancache-to-pg_prepared_statement.patch | text/x-diff | 11.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Magnus Hagander | 2020-07-14 12:25:35 | Re: recovering from "found xmin ... from before relfrozenxid ..." |
Previous Message | Amit Kapila | 2020-07-14 12:09:54 | Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions |