Re: [PATCH] backend: compare word-at-a-time in bcTruelen - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCH] backend: compare word-at-a-time in bcTruelen
Date
Msg-id 22169.1245984538@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCH] backend: compare word-at-a-time in bcTruelen  (Jeremy Kerr <jk@ozlabs.org>)
Responses Re: [PATCH] backend: compare word-at-a-time in bcTruelen  (Jeremy Kerr <jk@ozlabs.org>)
List pgsql-hackers
Jeremy Kerr <jk@ozlabs.org> writes:
> I've put together some data from a microbenchmark of the bcTrulen 
> function, patched and unpatched.

Uh, where's the data?

> In the worst cases, I see a 53% cost increase on x86 (with the string 
> 'aaa ') and a 97% increase on PowerPC ('a  ').
> So, it all depends on the number of padding spaces we'd expect to see on 
> workload data. Fortunately, we see the larger reductions on the more 
> expensive operations (ie, longer strings).

Unfortunately, the cases with lots of padding spaces are probably much
less probable than the cases with fewer.  It would be unpleasant for
example if this patch resulted in a severe performance degradation for
a "canonical" example of char(n) being used properly, such as char(2)
for US state abbreviations.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Itagaki Takahiro
Date:
Subject: query cancel issues in contrib/dblink
Next
From: Jeremy Kerr
Date:
Subject: Re: [PATCH] backend: compare word-at-a-time in bcTruelen