On Fri, Jun 12, 2020 at 11:28 PM Robert Haas <robertmh...@gmail.com> wrote: > > On Thu, Jun 11, 2020 at 4:54 PM David Rowley <dgrowle...@gmail.com> wrote: > > I think someone at some point is not going to like the automatic > > choice. So perhaps a reloption to allow users to overwrite it is a > > good idea. -1 should most likely mean use the automatic choice based > > on relation size. I think for parallel seq scans that filter a large > > portion of the records most likely need some sort of index, but there > > are perhaps some genuine cases for not having one. e.g perhaps the > > query is just not run often enough for an index to be worthwhile. In > > that case, the performance is likely less critical, but at least the > > reloption would allow users to get the old behaviour. > > Let me play the devil's advocate here. I feel like if the step size is > limited by the relation size and there is ramp-up and ramp-down, or > maybe even if you don't have all 3 of those but perhaps say 2 of them, > the chances of there being a significant downside from using this seem > quite small. At that point I wonder whether you really need an option. > It's true that someone might not like it, but there are all sorts of > things that at least one person doesn't like and one can't cater to > all of them. > > To put that another way, in what scenario do we suppose that a > reasonable person would wish to use this reloption? >
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. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
