| From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Subplan result caching |
| Date: | 2018-10-02 02:21:06 |
| Message-ID: | CAKJS1f89DQNk_jB5_2wy4qwnyKZ01xPaD8JHbqyW9BqA5ejRrQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 19 July 2018 at 06:27, Robert Haas <robertmhaas(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2018-10-02 02:21:58 | Re: TupleTableSlot abstraction |
| Previous Message | Michael Paquier | 2018-10-02 02:16:26 | Re: POC: GROUP BY optimization |