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

torikoshia <torikoshia@oss.nttdata.com>

From: torikoshia <torikoshia@oss.nttdata.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: tatsuro.yamada.tf@nttcom.co.jp, sunchengxi@highgo.com, pgsql-hackers@postgresql.org, masao.fujii@oss.nttdata.com, pavel.stehule@gmail.com, legrand_legrand@hotmail.com
Date: 2021-02-08T05:02:23Z
Lists: pgsql-hackers

Attachments

On 2021-02-04 11:19, Kyotaro Horiguchi wrote:
> At Thu, 04 Feb 2021 10:16:47 +0900, torikoshia
> <torikoshia@oss.nttdata.com> wrote in
>> Chengxi Sun, Yamada-san, Horiguchi-san,
>> 
>> Thanks for all your comments.
>> Adding only the number of generic plan execution seems acceptable.
>> 
>> On Mon, Jan 25, 2021 at 2:10 PM Kyotaro Horiguchi
>> <horikyota.ntt@gmail.com> wrote:
>> > Note that ActivePortal is the closest nested portal. So it gives the
>> > wrong result for nested portals.
>> 
>> I may be wrong, but I thought it was ok since the closest nested
>> portal is the portal to be executed.
> 
> After executing the inner-most portal, is_plan_type_generic has a
> value for the inner-most portal and it won't be changed ever after. At
> the ExecutorEnd of all the upper-portals see the value for the
> inner-most portal left behind is_plan_type_generic nevertheless the
> portals at every nest level are independent.
> 
>> ActivePortal is used in ExecutorStart hook in the patch.
>> And as far as I read PortalStart(), ActivePortal is changed to the
>> portal to be executed before ExecutorStart().
>> 
>> If possible, could you tell me the specific case which causes wrong
>> results?
> 
> Running a plpgsql function that does PREPRE in a query that does
> PREPARE?

Thanks for your explanation!

I confirmed that it in fact happened.

To avoid it, attached patch preserves the is_plan_type_generic before 
changing it and sets it back at the end of pgss_ExecutorEnd().

Any thoughts?


Regards,

--
Atsushi Torikoshi

Commits

  1. Add generic_plans and custom_plans fields into pg_prepared_statements.