On Thu, Oct 20, 2016 at 12:22 AM, Peter Geoghegan <p...@heroku.com> wrote:
> On Tue, Oct 4, 2016 at 11:05 PM, Rushabh Lathia > <rushabh.lat...@gmail.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? > > Yes, all other TPC-H queries where unaffected with the patch. At the initially stage of patch development I noticed the regressions, but then realize that it is because I am not allowing leader to participate in the GM. Later on I fixed that and after that I didn't noticed 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? > > Yes, but isn't that good? Please correct me if I am missing anything. > -- > Peter Geoghegan > -- Rushabh Lathia www.EnterpriseDB.com
