Re: Parallel Seq Scan vs kernel read ahead
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: David Rowley <dgrowleyml@gmail.com>,
Thomas Munro <thomas.munro@gmail.com>, Ranier Vilela <ranier.vf@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2020-06-16T10:57:26Z
Lists: pgsql-hackers
On Mon, Jun 15, 2020 at 8:59 PM Robert Haas <robertmhaas@gmail.com> wrote: > > On Sat, Jun 13, 2020 at 2:13 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > The performance can vary based on qualification where some workers > > discard more rows as compared to others, with the current system with > > step-size as one, the probability of unequal work among workers is > > quite low as compared to larger step-sizes. > > It seems like this would require incredibly bad luck, though. > I agree that won't be a common scenario but apart from that also I am not sure if we can conclude that the proposed patch won't cause any regressions. See one of the tests [1] done by Soumyadeep where the patch has caused regression in one of the cases, now we can either try to improve the patch and see we didn't cause any regressions or assume that those are some minority cases which we don't care. Another point is that this thread has started with a theory that this idea can give benefits on certain filesystems and AFAICS we have tested it on one other type of system, so not sure if that is sufficient. Having said that, I just want to clarify that I am positive about this work but just not very sure that it is a universal win based on the testing done till now. [1] - https://www.postgresql.org/message-id/CADwEdoqirzK3H8bB%3DxyJ192EZCNwGfcCa_WJ5GHVM7Sv8oenuA%40mail.gmail.com -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Commits
-
Allocate consecutive blocks during parallel seqscans
- 56788d2156fc 14.0 landed