| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Jeremy Kerr <jk(at)ozlabs(dot)org> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Gurjeet Singh <singh(dot)gurjeet(at)gmail(dot)com> |
| Subject: | Re: [PATCH] backend: compare word-at-a-time in bcTruelen |
| Date: | 2009-06-26 02:48:58 |
| Message-ID: | 22169.1245984538@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Jeremy Kerr <jk(at)ozlabs(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeremy Kerr | 2009-06-26 03:20:39 | Re: [PATCH] backend: compare word-at-a-time in bcTruelen |
| Previous Message | Itagaki Takahiro | 2009-06-26 02:41:37 | query cancel issues in contrib/dblink |