| From: | Jeremy Kerr <jk(at)ozlabs(dot)org> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 12:47:00 |
| Message-ID: | 200906262047.00727.jk@ozlabs.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Stephen,
> If the updated function is always faster when the overall string is at
> least, say, 16 characters long,
But that's not the case - the cost of the function (and the speedup from
the previous version) depends on the number of spaces that there are at
the end.
For the new function to be faster, we need to know that there are more
than 6 (on average, depending on alignment) trailing spaces. The number
of non-space characters in the string won't affect performance (other
than that there is probably a correlation between total string length
and number of spaces, but we can't be certain of that).
> If the new function is always slower, regardless of overall string
> length, when there's only 1 extra space at the end
Yes, that is correct.
Cheers,
Jeremy
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alexey Bashtanov | 2009-06-26 12:54:22 | BUG #4887: inclusion operator (@>) on tsqeries behaves not conforming to documentation |
| Previous Message | Stephen Frost | 2009-06-26 12:12:12 | Re: [PATCH] backend: compare word-at-a-time in bcTruelen |