| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
| Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> |
| Subject: | Re: What to call an executor node which lazily caches tuples in a hash table? |
| Date: | 2021-03-31 21:19:31 |
| Message-ID: | 20210331211931.ytsy6u2xxn526uny@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2021-03-31 12:29:36 +1300, David Rowley wrote:
> Here's a list of a few that were mentioned:
>
> Probe Cache
> Tuple Cache
> Keyed Materialize
> Hash Materialize
> Result Cache
> Cache
> Hash Cache
> Lazy Hash
> Reactive Hash
> Parameterized Hash
> Parameterized Cache
> Keyed Inner Cache
> MRU Cache
> MRU Hash
Suggestion: ParamKeyedCache.
I don't like Parameterized because it makes it sound like the cache is
parameterized (e.g. size), rather than using Param values as the keys
for the cache. ParamKeyed indicates that Params are the key, rather
than configuring the cache...
I don't like "result cache" all that much, because it does sound like
we'd be caching query results etc, or that it might be referring to
Result nodes. Neither of which is the case...
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | 'alvherre@alvh.no-ip.org' | 2021-03-31 21:21:10 | Re: libpq debug log |
| Previous Message | Vik Fearing | 2021-03-31 21:18:14 | Re: Idea: Avoid JOINs by using path expressions to follow FKs |