| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | 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: Parallel tuplesort (for parallel B-Tree index creation) |
| Date: | 2017-03-20 01:03:51 |
| Message-ID: | CAH2-WznqgFJVb0OpbrS445TnyS8ib8kSxAASvLqLCaSnQeyd0Q@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Mar 12, 2017 at 3:05 PM, Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> I attach my V9 of the patch. I came up some stuff for the design of
> resource management that I think meets every design goal that we have
> for shared/unified BufFiles:
Commit 2609e91fc broke the parallel CREATE INDEX cost model. I should
now pass -1 as the index block argument to compute_parallel_worker(),
just as all callers that aren't parallel index scan do after that
commit. This issue caused V9 to never choose parallel CREATE INDEX
within nbtsort.c. There was also a small amount of bitrot.
Attached V10 fixes this regression. I also couldn't resist adding a
few new assertions that I thought were worth having to buffile.c, plus
dedicated wait events for parallel tuplesort. And, I fixed a silly bug
added in V9 around where worker_wait() should occur.
--
Peter Geoghegan
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Add-parallel-B-tree-index-build-sorting.patch.gz | application/x-gzip | 56.0 KB |
| 0002-Add-temporary-testing-tools.patch.gz | application/x-gzip | 4.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Vaishnavi Prabakaran | 2017-03-20 01:32:15 | Re: PATCH: Batch/pipelining support for libpq |
| Previous Message | Peter Eisentraut | 2017-03-20 00:46:48 | Re: Removing binaries (was: createlang/droplang deprecated) |