On Tue, Apr 8, 2014 at 10:10 AM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> Right. But 1) is the baseline we need to evaluate 2) against.
I don't agree with that. Surely we're concerned with not regressing
cases that people actually care about, which in practical terms means
the changes of a single release. While I guess I'm fine with
structuring the patch like that, I don't think it's fair that the
strxfrm() stuff doesn't get credit for not regressing those cases so
badly just because they're only ameliorated by the fmgr-eliding stuff.
While I'm concerned about worst case performance myself, I don't want
to worry about Machiavelli rather than Murphy. What collation did you
use for your test-case?
The fmgr-eliding stuff is only really valuable in that it ameliorates
the not-so-bad regressions, and is integral to the strxfrm() stuff.
Let's not lose sight of the fact that (if we take TPC style benchmarks
as representative) the majority of text sorts can be made at least 3
times faster.
--
Peter Geoghegan
