Re: Subplan result caching

On Mon, Jul 9, 2018 at 5:08 AM, David Rowley
<david.rowley@2ndquadrant.com> wrote:
> From looking at the code I see that the caching is being done inside
> nodeSubplan.c. I don't think this is the right approach to the
> problem. The problem exists for any parameterized path, so I think a
> more general approach would be much better.

Yeah, perhaps, though sometimes a more specific problem is easier to solve.

> "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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company