On Sun, Mar 24, 2019 at 11:06 AM David Rowley <david.row...@2ndquadrant.com> wrote: > > On Sat, 23 Mar 2019 at 19:42, Tom Lane <t...@sss.pgh.pa.us> wrote: > > > > 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, > > Here's a version with it done that way.
FTR this patch doesn't apply since single child [Merge]Append suppression (8edd0e7946) has been pushed.
