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