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

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.

Peter Geoghegan

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to