Re: Is it useful to record whether plans are generic or custom?
От | torikoshia |
---|---|
Тема | Re: Is it useful to record whether plans are generic or custom? |
Дата | |
Msg-id | 0268e34577c1d516c8beb12cb0ccc1a7@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: Is it useful to record whether plans are generic or custom? (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Список | pgsql-hackers |
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
Вложения
В списке pgsql-hackers по дате отправления: