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. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
mergeappend_to_append_conversion_v13.patch
Description: Binary data
