Re: Subplan result caching
От
Robert Haas
Тема
Re: Subplan result caching
Дата
Msg-id
CA+TgmoZYefMioZWaicAderT=XUqmP3B6aZE9r9PRa8axhFQaHw@mail.gmail.com
Ответ на
Re: Subplan result caching (David Rowley)
Список
Дерево обсуждения
Subplan result caching Heikki Linnakangas <hlinnaka@iki.fi>
Re: Subplan result caching Laurenz Albe <laurenz.albe@cybertec.at>
Re: Subplan result caching Robert Haas <robertmhaas@gmail.com>
Re: Subplan result caching Vladimir Sitnikov <sitnikov.vladimir@gmail.com>
Re: Subplan result caching Tom Lane <tgl@sss.pgh.pa.us>
Re: Subplan result caching David Rowley <david.rowley@2ndquadrant.com>
Re: Subplan result caching Heikki Linnakangas <hlinnaka@iki.fi>
Re: Subplan result caching Tom Lane <tgl@sss.pgh.pa.us>
Re: Subplan result caching Andres Freund <andres@anarazel.de>
Re: Subplan result caching Robert Haas <robertmhaas@gmail.com>
Re: Subplan result caching Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Re: Subplan result caching David Rowley <david.rowley@2ndquadrant.com>
Re: Subplan result caching Michael Paquier <michael@paquier.xyz>
Re: Subplan result caching Robert Haas <robertmhaas@gmail.com>
Re: Subplan result caching David Rowley <david.rowley@2ndquadrant.com>
Re: Subplan result caching Andy Fan <zhihui.fan1213@gmail.com>
Re: Subplan result caching David Rowley <dgrowleyml@gmail.com>
Re: Subplan result caching Andy Fan <zhihui.fan1213@gmail.com>
Re: Subplan result caching David Rowley <dgrowleyml@gmail.com>
Re: Subplan result caching Andy Fan <zhihui.fan1213@gmail.com>
Re: Subplan result caching David Rowley <david.rowley@2ndquadrant.com>
On Mon, Jul 9, 2018 at 5:08 AM, David Rowley 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
В списке pgsql-hackers по дате отправления