Re: B-Tree support function number 3 (strxfrm() optimization)

On 04/07/2014 09:19 PM, Peter Geoghegan wrote:
> The only case that this patch could possibly regress is where there
> are strings that differ beyond about the first 8 bytes, but are not
> identical (we chance a memcmp() == 0 before doing a full strcoll()
> when tie-breaking on the semi-reliable initial comparison). We still
> always avoid fmgr-overhead (and shim overhead, which I've measured),
> as in your original patch - you put that at adding 7% at the time,
> which is likely to make up for otherwise-regressed cases. There is
> nothing at all contrived about my test-case.

Did I understand correctly that this patch actually does two things:

1. Avoid fmgr and shim overhead
2. Use strxfrm to produce a pseudo-leading key that's cheaper to compare.

In that case, these changes need to be analyzed separately. You don't
get to "make up" for the losses by the second part by the gains from the
first part. We could commit just the first part (for 9.5!), and that has
to be the baseline for the second part.

This is very promising stuff, but it's not a slam-dunk win. I'd suggest
adding these to the next commitfest, as two separate patches.

- Heikki