From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Rushabh Lathia <rushabh(dot)lathia(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Gather Merge |
Date: | 2016-10-19 18:52:08 |
Message-ID: | CAM3SWZQBphsBmXN4NWTNG9Ws8QyTLAXZzx=+ZL4gFVWypSN-gQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Oct 4, 2016 at 11:05 PM, Rushabh Lathia
<rushabh(dot)lathia(at)gmail(dot)com> wrote:
> Query 4: With GM 7901.480 -> Without GM 9064.776
> Query 5: With GM 53452.126 -> Without GM 55059.511
> Query 9: With GM 52613.132 -> Without GM 98206.793
> Query 15: With GM 68051.058 -> Without GM 68918.378
> Query 17: With GM 129236.075 -> Without GM 160451.094
> Query 20: With GM 259144.232 -> Without GM 306256.322
> Query 21: With GM 153483.497 -> Without GM 168169.916
>
> Here from the results we can see that query 9, 17 and 20 are the one which
> show good performance benefit with the Gather Merge.
Were all other TPC-H queries unaffected? IOW, did they have the same
plan as before with your patch applied? Did you see any regressions?
I assume that this patch has each worker use work_mem for its own
sort, as with hash joins today. One concern with that model when
testing is that you could end up with a bunch of internal sorts for
cases with a GM node, where you get one big external sort for cases
without one. Did you take that into consideration?
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2016-10-19 18:55:30 | Re: Remove vacuum_defer_cleanup_age |
Previous Message | Peter Geoghegan | 2016-10-19 18:33:32 | Re: Parallel tuplesort (for parallel B-Tree index creation) |