Hi,
On 2021-11-05 08:34:26 -0400, Robert Haas wrote:
> I'm not sure why that requires all of this relative pointer stuff,
> honestly. Under that problem statement, we don't need everything to be
> one contiguous allocation. We just need it to have the same lifespan
> as the JITted code. If you introduced no relative pointers at all,
> you could still solve this problem: create a new memory context that
> contains all of the EvalExprSteps and all of the allocations upon
> which they depend, make sure everything you care about is allocated in
> that context, and don't destroy any of it until you destroy it all.
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.
> 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.
Greetings,
Andres Freund
