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. +
