Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)
| От | Peter Geoghegan |
|---|---|
| Тема | Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation) |
| Дата | |
| Msg-id | CAH2-WzmKcdTfOWe8=suE5EGnt+xQgqyj+rF2=OruQ13=1=Wx_g@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation) (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)
|
| Список | pgsql-hackers |
On Fri, Jan 26, 2018 at 10:33 AM, Robert Haas <robertmhaas@gmail.com> wrote: > I'm busy with other things, so no rush. Got it. There is one question that I should probably get clarity on ahead of the next revision, which is: Should I rip out the code that disallows a "degenerate parallel CREATE INDEX" when parallel_leader_participation=off, or should I instead rip out any code that deals with parallel_leader_participation, and always have the leader participate as a worker? If I did the latter, then leader non-participation would live on as a #define debug option within nbtsort.c. It definitely seems like we'd want to preserve that at a minimum. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: