Stefan,
* Stefan Kaltenbrunner (stefan@kaltenbrunner.cc) wrote:
> Stephen Frost wrote:
>> 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).
What I'm suggesting is to test what happens when strings sent to
bcTruelen are at different memory addresses (there's only 4 or 8
different possibilities here, then different lengths should be tested of
less-than-1-word, 1-word, >1-word, and then different ending points at
different memory addresses) and compare the new function to the old.
The main point here being to try and find out if there are any
pathological cases where the new function is much worse, or even
somewhat worse, so we can weigh that against the places where it
performs better.
This isn't something you can do from in PG. :)
> 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)
Certainly, your performance numbers are good justification if there's no
downside.
Thanks,
Stephen
