Stephen Frost wrote:
* Stefan Kaltenbrunner (ste...@kaltenbrunner.cc) wrote:
FWIW: I'm able to measure an even more significant improvement of around
10%:
What would be really useful would be "best case" and "worst case"
scenarios. Ideally, with profile information for this specific function
(in addition to full benchmark runs since those can show minimal
performance improvments due to other constraints, locking, etc).
not sure what you are after here - my testcase is one specific query run
in parallel on 16 processes (running it in a single process yields
similiar improvements our scaling is pretty good here).
Have you tried pulling this function out and running tests with all
alignment possibilities to see how it compares to the original? There's
only so many options and showing that this change always improves
performance, or at least doesn't degrade it in the worst case, would
certainly go a long way towards getting it accepted.
again I'm not exactly sure on what you want to get tested specifically -
the original problem report was because I noticed a significant
performance improvement from using varchar() instead of char(n) and that
showed bcTruelen() on the very top of the profile.
I was simply testing the patch Jeremy provided on that workload(the
upthread mentioned query is mostly affected by that on others there is
no measurable difference)
Stefan
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
