Re: WIP: expression evaluation improvements

Hi,

On 2021-11-05 13:09:10 -0400, Robert Haas wrote:
> On Fri, Nov 5, 2021 at 12:48 PM Andres Freund <andres@anarazel.de> wrote:
> > I don't see how that works - the same expression can be evaluated multiple
> > times at once, recursively. So you can't have things like FunctionCallInfoData
> > shared. One key point of separating out the mutable data into something that
> > can be relocated is precisely so that every execution can have its own
> > "mutable" data area, without needing to change anything else.
> 
> Oh. That makes it harder.

Yes. Optimally we'd do JIT caching across connections as well. One of the
biggest issues with the costs of JITing is actually parallel query, where
we'll often recreate the same JIT code again and again. For that you really
can't have much in the way of pointers...


> > > Or another option would be: instead of having one giant allocation in which
> > > we have to place data of every different type, have one allocation per kind
> > > of thing. Figure out how many FunctionCallInfo objects we need and make an
> > > array of them. Figure out how many NullableDatum objects we need and make a
> > > separate array of those. And so on. Then just use pointers.
> >
> > Without the relative pointer thing you'd still have pointers into those arrays
> > of objects. Which then would make the thing non-shareable.
> 
> Well, I guess you could store indexes into the individual arrays, but
> then I guess you're not gaining much of anything.

You'd most likely just loose a bit of locality, because the different types of
data are now all on separate cachelines, even if referenced by the one
expression step.


> It's a pretty annoying problem, really. Somehow it's hard to shake the
> feeling that there ought to be a better approach than relative
> pointers.

Yes. I don't like it much either :(. Basically native code has the same issue,
and also largely ended up with making most things relative (see x86-64 which
does most addressing relative to the instruction pointer, and binaries
pre-relocation, where the addresses aren't resolved yed).

Greetings,

Andres Freund