On 03/16/2018 09:47 AM, Alexander Korotkov wrote: > On Fri, Mar 16, 2018 at 5:12 AM, Tomas Vondra > <tomas.vondra@2ndquadrant.com <mailto:tomas.vondra@2ndquadrant.com>> wrote: > > I agree those don't seem like an issue in the Incremental Sort patch, > but like a more generic costing problems. > > > Yes, I think so too.
I wonder if we could make the costing a bit more pessimistic, to make these loses less likely, while still keeping the main wins (particularly for the LIMIT queries). But that seems a bit like a lost case, I guess.
Making costing more pessimistic makes sense. Revised patch does
it in quite rough way: volumes of groups in incremental sort are multiplied
by 1.5. That makes one query in regression tests to fallback to fullsort
from incremental sort. Could you test it? If this will shorten number of
cases where incremental sort causes regression, then it might be an
acceptable way to do more pessimistic costing.
> Do you think we can mark this patch RFC assuming that it have > already got pretty much of review previously. >
Actually, I was going to propose to switch it to RFC, so I've just done that. I think the patch is clearly ready for a committer to take a closer look. I really like this improvement.
I'm going to rerun the tests, but that's mostly because I'm interested if the change from i++ to i-- in cmpSortPresortedCols makes a measurable difference. I don't expect to find any issues, so why wait with the RFC?