On Sat, 9 Mar 2019 at 10:52, Tom Lane <t...@sss.pgh.pa.us> wrote: > > Julien Rouhaud <rjuju...@gmail.com> writes: > > On Fri, Mar 8, 2019 at 9:15 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > >> I think you should remove all that > >> and restrict this optimization to the case where all the subpaths are > >> natively ordered --- if we have to insert Sorts, it's hardly going to move > >> the needle to worry about simplifying the parent MergeAppend to Append. > > > This can be a huge win for queries of the form "ORDER BY partkey LIMIT > > x". Even if the first subpath(s) aren't natively ordered, not all of > > the sorts should actually be performed. > > [ shrug... ] We've got no realistic chance of estimating such situations > properly, so I'd have no confidence in a plan choice based on such a > thing. Nor do I believe that this case is all that important.
Hi Tom, Wondering if you can provide more details on why you think there's no realistic chance of the planner costing these cases correctly? It would be unfortunate to reject this patch based on a sentence that starts with "[ shrug... ]", especially so when three people have stood up and disagreed with you. I've explained why I think you're wrong. Would you be able to explain to me why you think I'm wrong? You also mentioned that you didn't like the fact I'd changed the API for create_append_plan(). Could you suggest why you think passing pathkeys in is the wrong thing to do? The Append path obviously needs pathkeys so that upper paths know what order the path guarantees. Passing pathkeys in allows us to verify that pathkeys are a valid thing to have for the AppendPath. They're not valid in the Parallel Append case, for example, so setting them afterwards does not seem like an improvement. They also allow us to cost the cheaper startup cost properly, however, you did seem to argue that you have no confidence in cheap startup plans, which I'm still confused by. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
