Re: Defer selection of asynchronous subplans until the executor initialization stage

From: Zhihong Yu <zyu(at)yugabyte(dot)com>
To: Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>
Cc: Justin Pryzby <pryzby(at)telsasoft(dot)com>, Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru>, "Andrey V(dot) Lepikhov" <a(dot)lepikhov(at)postgrespro(dot)ru>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Defer selection of asynchronous subplans until the executor initialization stage
Date: 2022-04-17 10:34:55
Message-ID: CALNJ-vSPQQz99DCdyNTKxQxKERKfv7LmdE_0jdC=2_6cQ6vZAQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Apr 17, 2022 at 1:48 AM Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com>
wrote:

> On Mon, Apr 11, 2022 at 11:44 AM Zhihong Yu <zyu(at)yugabyte(dot)com> wrote:
> > On Sun, Apr 10, 2022 at 7:41 PM Justin Pryzby <pryzby(at)telsasoft(dot)com>
> wrote:
> >> On Sun, Apr 10, 2022 at 06:46:25AM -0700, Zhihong Yu wrote:
> >> > Looking at the second hunk of the patch:
> >> > FdwRoutine *fdwroutine = path->parent->fdwroutine;
> >> > ...
> >> > + if (IsA(plan, Result))
> >> > + return false;
> >> >
> >> > It seems the check of whether plan is a Result node can be lifted
> ahead of
> >> > the switch statement (i.e. to the beginning of
> mark_async_capable_plan).
> >> >
> >> > This way, we don't have to check for every case in the switch
> statement.
> >>
> >> I think you misread it - the other branch says: if (*not* IsA())
> >>
> > No, I didn't misread:
> >
> > if (!IsA(plan, Result) &&
> > mark_async_capable_plan(plan,
> > ((ProjectionPath *)
> path)->subpath))
> > return true;
> > return false;
> >
> > If the plan is Result node, false would be returned.
> > So the check can be lifted to the beginning of the func.
>
> I think we might support more cases in the switch statement in the
> future. My concern about your proposal is that it might make it hard
> to add new cases to the statement. I agree that what I proposed has a
> bit of redundant code, but writing code inside each case independently
> would make it easy to add them, making code consistent across branches
> and thus making back-patching easy.
>
> Thanks for reviewing!
>
> Best regards,
> Etsuro Fujita
>
Hi,
When a new case arises where the plan is not a Result node, this func can
be rewritten.
If there is only one such new case, the check at the beginning of the func
can be tuned to exclude that case.

I still think the check should be lifted to the beginning of the func
(given the current cases).

Cheers

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jesper Pedersen 2022-04-17 12:05:19 Re: GsoC: pgexporter: Custom file
Previous Message Etsuro Fujita 2022-04-17 09:20:48 postgres_fdw: batch inserts vs. before row triggers