On Fri, Jun 12, 2020 at 2:24 AM David Rowley <dgrowle...@gmail.com> wrote: > > On Thu, 11 Jun 2020 at 23:35, Amit Kapila <amit.kapil...@gmail.com> wrote: > > Another point I am thinking is that whatever formula we come up here > > might not be a good fit for every case. For ex. as you mentioned > > above that larger step-size can impact the performance based on > > qualification, similarly there could be other things like having a > > target list or qual having some function which takes more time for > > certain tuples and lesser for others especially if function evaluation > > is based on some column values. So, can we think of providing a > > rel_option for step-size? > > 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. >
makes sense to me. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com