Re: Subplan result caching - Mailing list pgsql-hackers

From David Rowley
Subject Re: Subplan result caching
Date
Msg-id CAKJS1f89DQNk_jB5_2wy4qwnyKZ01xPaD8JHbqyW9BqA5ejRrQ@mail.gmail.com
Whole thread Raw
In response to Re: Subplan result caching  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 19 July 2018 at 06:27, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Jul 9, 2018 at 5:08 AM, David Rowley
>> "LazyMaterialize" seems like a good option for a name. It seems better
>> than "LazyHash" since you may not want to restrict it to a hash table
>> based cache in the future.  A binary search tree may be a good option
>> for types that cannot be hashed.
>
> I think that's not too clear, actually.  The difference between a
> Materialize and a LazyMaterialize is not that this is lazy and that's
> not.  It's that this can cache multiple result sets for various
> parameter values and that can only cache one result set.

Okay. I'm not going to argue with the name of a node type that does
not exist yet. I was more suggesting that it should be a modular
component that we can plug into whatever plan types suit it. My
suggestions for naming was admittedly more of a sales tactic to gain
support for the idea, which perhaps failed.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: POC: GROUP BY optimization
Next
From: Tom Lane
Date:
Subject: Re: TupleTableSlot abstraction