On Tue, Apr 8, 2014 at 12:31 PM, Robert Haas <robertmh...@gmail.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_8is26vl...@mail.gmail.com -- 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
