Hi Amit, The latest v16 patch cannot be applied to the latest master as is. 434873806a9b1c0edd53c2a9df7c93a8ba021147 changed various lines in heapam.c, so it probably conflicts with this.
[kaigai@magro sepgsql]$ cat ~/patch/parallel_seqscan_v16.patch | patch -p1 patching file src/backend/access/common/printtup.c patching file src/backend/access/heap/heapam.c Hunk #4 succeeded at 499 (offset 10 lines). Hunk #5 succeeded at 533 (offset 10 lines). Hunk #6 FAILED at 678. Hunk #7 succeeded at 790 (offset 10 lines). Hunk #8 succeeded at 821 (offset 10 lines). Hunk #9 FAILED at 955. Hunk #10 succeeded at 1365 (offset 10 lines). Hunk #11 succeeded at 1375 (offset 10 lines). Hunk #12 succeeded at 1384 (offset 10 lines). Hunk #13 succeeded at 1393 (offset 10 lines). Hunk #14 succeeded at 1402 (offset 10 lines). Hunk #15 succeeded at 1410 (offset 10 lines). Hunk #16 succeeded at 1439 (offset 10 lines). Hunk #17 succeeded at 1533 (offset 10 lines). 2 out of 17 hunks FAILED -- saving rejects to file src/backend/access/heap/heapam.c.rej : Thanks, -- NEC Business Creation Division / PG-Strom Project KaiGai Kohei <kai...@ak.jp.nec.com> > -----Original Message----- > From: pgsql-hackers-ow...@postgresql.org > [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of Amit Kapila > Sent: Thursday, July 23, 2015 8:43 PM > To: Robert Haas > Cc: Haribabu Kommi; Gavin Flower; Jeff Davis; Andres Freund; Kaigai Kouhei(海 > 外 浩平); Amit Langote; Amit Langote; Fabrízio Mello; Thom Brown; Stephen Frost; > pgsql-hackers > Subject: Re: [HACKERS] Parallel Seq Scan > > On Wed, Jul 22, 2015 at 9:14 PM, Robert Haas <robertmh...@gmail.com> wrote: > > > > One thing I noticed that is a bit dismaying is that we don't get a lot > > of benefit from having more workers. Look at the 0.1 data. At 2 > > workers, if we scaled perfectly, we would be 3x faster (since the > > master can do work too), but we are actually 2.4x faster. Each > > process is on the average 80% efficient. That's respectable. At 4 > > workers, we would be 5x faster with perfect scaling; here we are 3.5x > > faster. So the third and fourth worker were about 50% efficient. > > Hmm, not as good. But then going up to 8 workers bought us basically > > nothing. > > > > I think the improvement also depends on how costly is the qualification, > if it is costly, even for same selectivity the gains will be shown till higher > number of clients and for simple qualifications, we will see that cost of > having more workers will start dominating (processing data over multiple > tuple queues) over the benefit we can achieve by them. > > > With Regards, > Amit Kapila. > EnterpriseDB: http://www.enterprisedb.com <http://www.enterprisedb.com/> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
