Re: WIP: expression evaluation improvements
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2021-11-05T16:48:16Z
Lists: pgsql-hackers
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
Commits
-
Add special case fast-paths for strict functions
- d35d32d7112b 18.0 landed
-
Replace EEOP_DONE with special steps for return/no return
- 8dd7c7cd0a26 18.0 landed
-
jit: Reference expression step functions via llvmjit_types.
- b059d2f45685 13.0 landed
-
jit: Remove redundancies in expression evaluation code generation.
- e6f86f8dd983 13.0 landed
-
expression eval: Don't redundantly keep track of AggState.
- 1fdb7f9789c4 13.0 landed
-
jit: Reference functions by name in IOCOERCE steps.
- 8c2769405ff1 13.0 landed
-
expression eval, jit: Minor code cleanups.
- 1ec7679f1b67 13.0 landed