Peter Geoghegan wrote: > 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.
I think the point here is what matters is that that gain from the strxfrm part of the patch is large, regardless of what the baseline is (right?). If there's a small loss in an uncommon worst case, that's probably acceptable, as long as the worst case is uncommon and the loss is small. But if the loss is large, or the case is not uncommon, then a fix for the regression is going to be a necessity. You seem to be assuming that a fix for whatever regression is found is going to be impossible to find. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
