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

On Sat, Aug 2, 2014 at 1:15 AM, Heikki Linnakangas
<hlinnakangas(at)vmware(dot)com> wrote:
> Great, I'll wait for the patch.

I'll post something over the weekend.

> Do you mean:
>
> a) you don't understand what the patch should look like? or
> b) you don't understand why it's been requested?
>
> If a), I admit I don't remember the details of this patch or patches very
> well either, but looking back at the archives here:
> http://www.postgresql.org/message-id/CAM3SWZQVnuomFBWNHOyRQ8t+nVJp+3=e58jvvx_A9Y04QmHzrA@mail.gmail.com,
> I think you had a pretty solid idea of how the split should look like. So,
> please do that, i.e. post the patch that Robert did 2 years ago that gave
> the 7% speedup, rebased over master. I don't recall the details of that
> patch, so please explain briefly what it does, as if it was submitted for
> the first time.

Robert's 2012 patch just elides the fmgr overhead, like any sort
support routine, so you just go through a function pointer and not a
function pointer to a shim function with a fmgr call. It ends up
having the sort support routine do a dew things once that might
otherwise have to take place once per comparison. It's more or less a
basic sort support routine, and nothing more.

My question is: What is the reason for splitting the patch? Is it that
you or Robert don't agree with my assessment of the 2012 patch, and
you think there might be some subtlety to it that I'm not aware of? Do
you just want to do this incrementally because it's easier to digest
that way? This is a pertinent question. You said something about
understanding where the benefits come from here, which is fair, but my
point was that I actually do understand that the benefits clearly
mostly come from the new abbreviated key idea. As the author of the
2012 patch, I imagine that Robert must be pretty confident that's the
case too, but I don't want to presume that.

As I said, I don't have a problem with breaking out the patch. I am
not trying to artificially link the two. It just isn't obvious to me
that you're aware that most of the benefit, and indeed all of the
potential for regressions clearly comes from this abbreviated key
idea. So sure, we can break out the patch and commit the first part
fairly easily, almost entirely on the basis of 2012 discussion. What
you may have missed here is that the 2012 patch wasn't committed for
reasons entirely unrelated to the merit of the idea. If we were to
commit essentially the same 2012 patch, that is a very straightforward
matter, and is only a small fraction of our work here. The 2012 patch
really should have been committed in 2012.

--
Peter Geoghegan