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

On Tue, Apr 8, 2014 at 12:31 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> No, we're concerned about ending up with the best possible
> performance. That could mean applying the fmgr-elision but not the
> other part. Whether the other part is beneficial is based on how it
> compares to the performance post-fmgr-elision.

I agree with everything you say here, but I'm puzzled only because
it's overwhelmingly obvious that the strxfrm() stuff is where the
value is. You can dispute whether or not I should have made various
tweaks, and you probably should, but the basic value of that idea is
very much in evidence already. You yourself put the improvements of
fmgr-elision alone at ~7% back in 2012 [1]. At the time, Noah said
that he didn't think it was worth bothering with that patch for what
he considered to be a small gain, a view which I did not share at the
time.

What I have here looks like it speeds things up a little over 200% (so
a little over 300% of the original throughput) with a single client
for many representative cases. That's a massive difference, to the
point that I don't see a lot of sense in considering fmgr-elision
alone separately.

[1] http://www.postgresql.org/message-id/CA+Tgmoa8by24gd+YbuPX=5gSGmN0w5sGiPzWwq7_8iS26vL5CQ@mail.gmail.com
--
Peter Geoghegan