Re: [PATCH] backend: compare word-at-a-time in bcTruelen

Tom Lane wrote:
> 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.

What ever happened to this patch?

--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
+ If your life is a hard drive, Christ can be your backup. +