| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(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-18 18:30:46 |
| Message-ID: | CAH2-WzmwjO-2B07nM0LDP=KE3t4zWT9vt26rRXQCQHjD_OnG6g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jan 18, 2018 at 6:14 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> I see your point. OTOH, I think we should have something for testing
> purpose as that helps in catching the bugs and makes it easy to write
> tests that cover worker part of the code.
This is about the question of whether or not we want to allow
parallel_leader_participation to prevent or allow a parallel CREATE
INDEX that has 1 parallel worker that does all the sorting, with the
leader simply consuming its output without doing any merging (a
"degenerate paralllel CREATE INDEX"). It is perhaps only secondarily
about the question of ripping out parallel_leader_participation
entirely.
> Can you please elaborate what part of optimizer are you talking about
> where without leader participation partial path will always lose to a
> serial sequential scan path?
See my remarks to Robert just now.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2018-01-18 18:35:03 | Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation) |
| Previous Message | Tom Lane | 2018-01-18 18:28:16 | Re: master make check fails on Solaris 10 |