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

Tom Lane wrote:
> Jeremy Kerr <jk@ozlabs.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@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.comPG East:  http://www.enterprisedb.com/community/nav-pg-east-2010.do + If your life is a hard
drive,Christ can be your backup. +