David Rowley <david.row...@2ndquadrant.com> writes: > On Sat, 23 Mar 2019 at 05:40, Tom Lane <t...@sss.pgh.pa.us> wrote: >> BTW, another thing we could possibly do to answer this objection is to >> give the ordered-Append node an artificially pessimistic startup cost, >> such as the sum or the max of its children's startup costs. That's >> pretty ugly and unprincipled, but maybe it's better than not having the >> ability to generate the plan shape at all?
> I admit to having thought of that while trying to get to sleep last > night, but I was too scared to even suggest it. It's pretty much how > MergeAppend would cost it anyway. I agree it's not pretty to lie > about the startup cost, but it does kinda seem silly to fall back on a > more expensive MergeAppend when we know fine well Append is cheaper. Yeah. I'm starting to think that this might actually be the way to go, and here's why: my argument here is basically that a child plan that has a large startup cost is going to screw up our ability to estimate whether the parent Append is really a fast-start plan or not. Now, if we have to insert a Sort to make a child plan be correctly ordered, that clearly is a case where the child could have a large startup cost ... but what if a correctly-ordered child has a large startup cost for some other reason? Simply refusing to insert Sort nodes won't keep us out of the weeds if that's true. However, if we stick in a hack like the one suggested above, that will keep us from being too optimistic about the fast-start properties of the Append node no matter whether the problem arises from an added Sort node or is intrinsic to the child plan. It may well be that as things stand today, this scenario is only hypothetical, because we can only prove that a plain-Append plan is correctly sorted if it's arising from a suitably partitioned table, and the child plans in such cases will all be IndexScans with minimal startup cost. But we should look ahead to scenarios where that's not true. (mumble maybe a foreign table as a partition is already a counterexample? mumble) regards, tom lane