On Wed, 31 Mar 2021 at 14:43, Andy Fan <zhihui.fan1...@gmail.com> wrote: > At last, I still want to vote for "Tuple(s) Cache", which sounds simple and > enough. > I was thinking if we need to put "Lazy" in the node name since we do build > cache > lazily, then I found we didn't call "Materialize" as "Lazy Materialize", so > I think we > can keep consistent.
I thought about this a little more and I can see now why I put the word "Cache" in the original name. I do now agree we really need to keep the word "Cache" in the name. The EXPLAIN ANALYZE talks about "hits", "misses" and "evictions", all of those are things that caches do. -> Result Cache (actual rows=1 loops=403) Cache Key: c1.relkind Hits: 398 Misses: 5 Evictions: 0 Overflows: 0 Memory Usage: 1kB -> Aggregate (actual rows=1 loops=5) I don't think there's any need to put the word "Lazy" in the name as if we're keeping "Cache", then most caches do only cache results of values that have been looked for. I'm just not sure if "Tuple" is the best word or not. I primarily think of "tuple" as the word we use internally, but a quick grep of the docs reminds me that's not the case. The word is used all over the documents. We have GUCs like parallel_tuple_cost and cpu_tuple_cost. So it does seem like the sort of thing anyone who is interested in looking at the EXPLAIN output should know about. I'm just not massively keen on using that word in the name. The only other options that come to mind are "Result" and "Parameterized". However, I think "Parameterized" does not add much meaning. I think most people would expect a cache to have a key. I sort of see why I went with "Result Cache" now. Does anyone else like the name "Tuple Cache"? David