Re: Hybrid Hash/Nested Loop joins and caching results from subplans

On Fri, Nov 6, 2020 at 6:13 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:

> On Mon, 2 Nov 2020 at 20:43, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> >
> > On Tue, 20 Oct 2020 at 22:30, David Rowley <dgrowleyml(at)gmail(dot)com> wrote:
> > I did some further tests this time with some tuple deforming. Again,
> > it does seem that v9 is slower than v8.
> >
> > Graphs attached
> >
> > Looking at profiles, I don't really see any obvious reason as to why
> > this is. I'm very much inclined to just pursue the v8 patch (separate
> > Result Cache node) and just drop the v9 idea altogether.
>
> Nobody raised any objections, so I'll start taking a more serious look
> at the v8 version (the patch with the separate Result Cache node).
>
> One thing that I had planned to come back to about now is the name
> "Result Cache". I admit to not thinking for too long on the best name
> and always thought it was something to come back to later when there's
> some actual code to debate a better name for. "Result Cache" was
> always a bit of a placeholder name.
>
> Some other names that I'd thought of were:
>
> "MRU Hash"
> "MRU Cache"
> "Parameterized Tuple Cache" (bit long)
> "Parameterized Cache"
> "Parameterized MRU Cache"
>
>
I think "Tuple Cache" would be OK which means it is a cache for tuples.
Telling MRU/LRU would be too internal for an end user and "Parameterized"
looks redundant given that we have said "Cache Key" just below the node
name.

Just my $0.01.

--
Best Regards
Andy Fan