Tom Lane wrote: > Jeremy Kerr <j...@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 <br...@momjian.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. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
