Re: Redesigning the executor (async, JIT, memory efficiency)

On 2018-05-26 17:08:51 -0400, Robert Haas wrote:
> On Fri, May 25, 2018 at 2:40 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> > I think we're going to have to continue showing the tree plan. I think
> > the linear version is far too hard to understand for anything
> > nontrivial.
>
> Some of that is because this format is intrinsically hard to read, but
> it's also partly because of unfamiliarity and partly because you
> haven't put much work into it. You could certainly make it easier to
> read just by expending a little more effort on it:

Right - didn't seem like the highest priority thing to tackle. But
without displaying hierarchy even a lot of TLC won't make it easy to
understand. Being able to quickly ignore, or even hide if you use
something like explain.depesz.com, entire subtrees is quite valuable.
We don't compose programs in one function + a lot of goto statements for
a reason...

> Even with this sort of TLC, I agree that reading this is no picnic,
> but I think continuing to show the tree structure when the executing
> plan has been linearized seems to have its own set of difficulties.

I'm not so sure. The plan would still be in a tree form, and I do think
realistically people do and should care more about the planner choices
rather than minute details of how things are actually executed.
Especially if we're going to whack that around on a granular level
repeatedly.

> Also, consider a plan that today looks like this:
>
> Append
> -> Seq Scan on p1
> -> Seq Scan on p2
> -> Seq Scan on p3
>
> The linearized plan could omit the Append node altogether.

Sure, but instrumentation nodes could continue to have a reference to
the Plan/Append node as their parent.

> How will a linearized plan handle handle backward fetches?

I don't quite know yet, TBH. I'm playing with a few alternatives,
including:

a) Don't support it in general, require materialization at the top
level. Has the advantage of minimal complexity that's only incurred
when actually needed. And I think scrolling backwards is extremely
rare in practice.
b) Emit a separate execution program the first time a different
direction is required. But share enough state that the program can
just be switched over. That'd allow to remove all the necessary
branches to support backward scan from the hot paths.
c) Continue as currently done, essentially.

Greetings,

Andres Freund