On Tue, 14 Feb 2023 at 17:21, John Naylor <john.nay...@enterprisedb.com> wrote:
> Not rechecking seems to eliminate the regression in 4 cases, and reduce it in
> the other 2 cases. For those 2 cases (10e6 rows, random, mod 10 and 100), it
> might be worthwhile to "zoom in" with more measurements, but haven't done
> that yet.
Thanks for writing up this patch and for running those tests again.
I'm surprised to see there's a decent about of truth in the surplus
recheck of the first column in tiebreaks (mostly) causing the
regression. I really would have suspected CPU caching effects to be a
bigger factor. From looking at your numbers, it looks like it's just
the mod=100 test in random and unsorted. fallback-on looks faster than
master-off for random mod=10.
I didn't do a detailed review of the sort patch, but I did wonder
about the use of the name "fallback" in the new functions. The
comment in the following snippet from qsort_tuple_unsigned_compare()
makes me think "tiebreak" is a better name.
/*
* No need to waste effort calling the tiebreak function when there are no
* other keys to sort on.
*/
if (state->base.onlyKey != NULL)
return 0;
return state->base.comparetup_fallback(a, b, state);
I think if we fixed this duplicate recompare thing then I'd be much
more inclined to push the windowagg sort reduction stuff.
I also wonder if the weirdness I reported in [1] would also disappear
with your patch. There's a patch on that thread that hacks up the
planner to split multi-column sorts into Sort -> Incremental Sort
rather than just a single sort.
David
[1]
https://www.postgresql.org/message-id/CAApHDvpAO5H_L84kn9gCJ_hihOavtmDjimKYyftjWtF69BJ=8...@mail.gmail.com
