Re: [PATCH] backend: compare word-at-a-time in bcTruelen
От | Jeremy Kerr |
---|---|
Тема | Re: [PATCH] backend: compare word-at-a-time in bcTruelen |
Дата | |
Msg-id | 200906261120.39718.jk@ozlabs.org обсуждение исходный текст |
Ответ на | Re: [PATCH] backend: compare word-at-a-time in bcTruelen (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PATCH] backend: compare word-at-a-time in bcTruelen
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: