Re: Hybrid Hash/Nested Loop joins and caching results from subplans
От | David Rowley |
---|---|
Тема | Re: Hybrid Hash/Nested Loop joins and caching results from subplans |
Дата | |
Msg-id | CAApHDvoY-zCDKqrBVqvydLEPKQyGra=XWF62ygNBky_eJBvuDg@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: Hybrid Hash/Nested Loop joins and caching results from subplans ("houzj.fnst@fujitsu.com" <houzj.fnst@fujitsu.com>) |
Список | pgsql-hackers |
On Thu, 1 Apr 2021 at 23:41, houzj.fnst@fujitsu.com <houzj.fnst@fujitsu.com> wrote: > > > I've attached the updated patch. I'll let the CFbot grab this to ensure it's > > happy with it before I go looking to push it again. > > Hi, > > I took a look into the patch and noticed some minor things. > > 1. > + case T_ResultCache: > + ptype = "ResultCache"; > + subpath = ((ResultCachePath *) path)->subpath; > + break; > case T_UniquePath: > ptype = "Unique"; > subpath = ((UniquePath *) path)->subpath; > should we use "case T_ResultCachePath" here? > > 2. > Is it better to add ResultCache's info to " src/backend/optimizer/README " ? > Something like: > NestPath - nested-loop joins > MergePath - merge joins > HashPath - hash joins > + ResultCachePath - Result cache Thanks for pointing those two things out. I've pushed the patch again with some updates to EXPLAIN to fix the issue from yesterday. I also disabled result cache in the partition_prune tests as I suspect that the parallel tests there might just be a bit too unstable in the buildfarm. The cache hit/miss/eviction line might disappear if the main process does not get a chance to do any work. Well, it's now time to watch the buildfarm again... David
В списке pgsql-hackers по дате отправления: