Re: [HACKERS] why not parallel seq scan for slow functions
| От | Robert Haas |
|---|---|
| Тема | Re: [HACKERS] why not parallel seq scan for slow functions |
| Дата | |
| Msg-id | CA+TgmobUedr9ZT9yRC8CYMbO9sg7_y5zi7Jg+9zMt+UWJ2ttaA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] why not parallel seq scan for slow functions (Amit Kapila <amit.kapila16@gmail.com>) |
| Ответы |
Re: [HACKERS] why not parallel seq scan for slow functions
|
| Список | pgsql-hackers |
On Sun, Jan 28, 2018 at 10:13 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: > If we want to get rid of Gather (Merge) checks in > apply_projection_to_path(), then we need some way to add a projection > path to the subpath of gather node even if that is capable of > projection as we do now. I think changing the order of applying > scan/join target won't address that unless we decide to do it for > every partial path. Another way could be that we handle that in > generate_gather_paths, but I think that won't be the idle place to add > projection. > > If we want, we can compute the parallel-safety of scan/join target > once in grouping_planner and then pass it in apply_projection_to_path > to address your main concern. I spent some time today hacking on this; see attached. It needs more work, but you can see what I have in mind. It's not quite the same as what I outlined before because that turned out to not quite work, but it does remove most of the logic from apply_projection_to_path(). -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Вложения
В списке pgsql-hackers по дате отправления: