On Mon, Jul 9, 2018 at 5:08 AM, David Rowley <david.row...@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
