On Tue, Apr 8, 2014 at 10:10 AM, Heikki Linnakangas <hlinnakan...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
