On Tue, 11 Aug 2020 at 12:21, Andres Freund <and...@anarazel.de> wrote: > > On 2020-07-09 10:25:14 +1200, David Rowley wrote: > > On Thu, 9 Jul 2020 at 04:53, Andres Freund <and...@anarazel.de> wrote: > > > I'm not convinced it's a good idea to introduce a separate executor node > > > for this. There's a fair bit of overhead in them, and they will only be > > > below certain types of nodes afaict. It seems like it'd be better to > > > pull the required calls into the nodes that do parametrized scans of > > > subsidiary nodes. Have you considered that? > > > > I see 41 different node types mentioned in ExecReScan(). I don't > > really think it would be reasonable to change all those. > > But that's because we dispatch ExecReScan mechanically down to every > single executor node. That doesn't determine how many nodes would need > to modify to include explicit caching? What am I missing? > > Wouldn't we need roughly just nodeNestloop.c and nodeSubplan.c > integration?
hmm, I think you're right there about those two node types. I'm just not sure you're right about overloading these node types to act as a cache. How would you inform users via EXPLAIN ANALYZE of how many cache hits/misses occurred? What would you use to disable it for an escape hatch for when the planner makes a bad choice about caching? David
