| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
| Subject: | Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation) |
| Date: | 2018-01-26 19:04:03 |
| Message-ID: | CAH2-WzmKcdTfOWe8=suE5EGnt+xQgqyj+rF2=OruQ13=1=Wx_g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Jan 26, 2018 at 10:33 AM, Robert Haas <robertmhaas(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2018-01-26 19:17:01 | Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation) |
| Previous Message | Corey Huinker | 2018-01-26 18:57:54 | Re: \describe* |