| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)enterprisedb(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-13 13:34:09 |
| Message-ID: | CAA4eK1Jz79s6f9fguaXPDDuUUNPqGAyqWNJqFF7ZNzV59b7RXA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Jan 13, 2018 at 6:02 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> The patch uses both parallel_leader_participation and
> force_parallel_mode, but it seems the definition is different from
> what we have in Gather. Basically, even with force_parallel_mode, the
> leader is participating in parallel build. I see there is some
> discussion above about both these parameters and still, there is not
> complete agreement on the best way forward. I think we should have
> parallel_leader_participation as that can help in testing if nothing
> else.
>
Or maybe just have force_parallel_mode. I think one of these is
required to facilitate some form of testing of the parallel code
easily. As you can see from my previous email, it was quite easy to
demonstrate a test with force_parallel_mode.
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | John Naylor | 2018-01-13 13:37:54 | Re: WIP: a way forward on bootstrap data |
| Previous Message | Amit Kapila | 2018-01-13 12:32:42 | Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation) |