Tom, > > I've put together some data from a microbenchmark of the bcTrulen > > function, patched and unpatched. > > Uh, where's the data?
If you're after the raw data for a run, I've put it up: http://ozlabs.org/~jk/projects/db/data/bctruelen.csv I've also packaged up the quick-and-dirty benchmark I've been using: http://ozlabs.org/~jk/projects/db/bctrulen.tar.gz to recreate as-needed. ./benchmark.sh will run tests for varying-length strings (so changing the alignment) and varying numbers of trailing spaces. ./benchmark-bctruelen <str> will perform an individual old/new comparison. > Unfortunately, the cases with lots of padding spaces are probably > much less probable than the cases with fewer. It would be unpleasant > for example if this patch resulted in a severe performance > degradation for a "canonical" example of char(n) being used properly, > such as char(2) for US state abbreviations. Yep, makes sense. The other consideration is stock-ticker symbols, I assume they may also be stored in CHAR(small n) columns. Cheers, Jeremy -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
