| 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>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, 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 13:41:07 |
| Message-ID: | 4621.1246023667@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:
> 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.
Right, but there are certainly not more spaces than there are string
characters ;-)
I think Dimitri's idea is eminently worth trying. In a string of less
than, say, 16 bytes, the prospects of being able to win anything get
much smaller compared to the prospects of wasting the extra loop
overhead. There is also a DBA psychology angle to it. If you've got
CHAR(n) for very small n, it's likely that the type is being used in the
"canonical" fashion and there won't be many trailing blanks. The case
where we can hope to win is where we have CHAR(255) or some other
plucked-from-the-air limit.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2009-06-26 14:00:20 | Re: query cancel issues in contrib/dblink |
| Previous Message | Tom Lane | 2009-06-26 13:34:21 | gettext version problem exposed by buildfarm failures on "canary" |