On Mon, Feb 22, 2010 at 9:35 PM, Bruce Momjian <br...@momjian.us> wrote: > 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?
I think it's unclear that all of the best and worst cases have been sufficiently tested and that the results are satisfactory. We have everything from massive performance gains to no obvious benefit at all, and it's very unclear that anyone has made a serious effort to find a benchmark the worst-case scenarios. I think we should drop this for now. *If* someone wants to put some work into more thorough analysis for 9.1, we can revisit it then. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
