Re: Hybrid Hash/Nested Loop joins and caching results from subplans
| От | Robert Haas |
|---|---|
| Тема | Re: Hybrid Hash/Nested Loop joins and caching results from subplans |
| Дата | |
| Msg-id | CA+TgmoZMxLeanqrS00_p3xNsU3g1v3EKjNZ4dM02ShRxxLiDBw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Hybrid Hash/Nested Loop joins and caching results from subplans (David Rowley <dgrowleyml@gmail.com>) |
| Ответы |
Re: Hybrid Hash/Nested Loop joins and caching results from subplans
|
| Список | pgsql-hackers |
On Wed, May 20, 2020 at 7:44 AM David Rowley <dgrowleyml@gmail.com> wrote: > I've attached a patch which implements this. The new node type is > called "Result Cache". I'm not particularly wedded to keeping that > name, but if I change it, I only want to do it once. I've got a few > other names I mind, but I don't feel strongly or confident enough in > them to go and do the renaming. This is cool work; I am going to bikeshed on the name for a minute. I don't think Result Cache is terrible, but I have two observations: 1. It might invite confusion with a feature of some other database systems where they cache the results of entire queries and try to reuse the entire result set. 2. The functionality reminds me a bit of a Materialize node, except that instead of overflowing to disk, we throw away cache entries, and instead of caching just one result, we potentially cache many. I can't really think of a way to work Materialize into the node name and I'm not sure it would be the right idea anyway. But I wonder if maybe a name like "Parameterized Cache" would be better? That would avoid confusion with any other use of the phrase "result cache"; also, an experienced PostgreSQL user might be more likely to guess how a "Parameterized Cache" is different from a "Materialize" node than they would be if it were called a "Result Cache". Just my $0.02, -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: