Re: sortsupport for text
От | Peter Geoghegan |
---|---|
Тема | Re: sortsupport for text |
Дата | |
Msg-id | CAEYLb_WWQS0gV9VeHueganvTJtnRFgXCiiAEmaajzt9VBBQpLw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: sortsupport for text (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: sortsupport for text
(Peter Geoghegan <peter@2ndquadrant.com>)
Re: sortsupport for text (Florian Pflug <fgp@phlo.org>) |
Список | pgsql-hackers |
On 20 June 2012 17:41, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Peter Geoghegan <peter@2ndquadrant.com> writes: >> No, I'm suggesting it would probably be at least a bit of a win here >> to cache the constant, and only have to do a strxfrm() + strcmp() per >> comparison. > > Um, have you got any hard evidence to support that notion? The > traditional advice is that strcoll is faster than using strxfrm unless > the same strings are to be compared repeatedly. I'm not convinced that > saving the strxfrm on just one side will swing the balance. I've written a very small C++ program, which I've attached, that basically proves that this can still make a fairly large difference - I hope it's okay that that it's C++, but that allowed me to write the program quickly, with no dependencies for anyone who cares to try this out, other than a C++ compiler and the standard library. It just inserts 500,000 elements (the same succession of psuedo-random strings again and again) into a std::set, which is implemented using a red-black tree on my machine. In one case, we just use strcmp() (there is actually no tie-breaker). In the other case, the comparator allocates and fills memory for a strxfrm blob when needed, caches it, and uses strxfrm() to generate blobs for other elements into a dedicated buffer which persists across comparisons. It prints the duration of each run, and a running average for each case until terminated. Here is what the output looks like on my machine: [peter@peterlaptop strxfrm_test]$ g++ -O2 set_test.cpp [peter@peterlaptop strxfrm_test]$ ./a.out Time elapsed with strcoll: 1.485290 seconds Time elapsed with strxfrm optimization: 1.070211 seconds Time elapsed with strcoll: 1.813725 seconds Time elapsed with strxfrm optimization: 1.097950 seconds Time elapsed with strcoll: 1.813381 seconds Time elapsed with strxfrm optimization: 1.102769 seconds Time elapsed with strcoll: 1.826708 seconds Time elapsed with strxfrm optimization: 1.105093 seconds Time elapsed with strcoll: 1.842156 seconds Time elapsed with strxfrm optimization: 1.103198 seconds *****strcoll average: 1.756252 strxfrm average: 1.095844***** Time elapsed with strcoll: 1.834785 seconds Time elapsed with strxfrm optimization: 1.105369 seconds Time elapsed with strcoll: 1.817449 seconds Time elapsed with strxfrm optimization: 1.110386 seconds Time elapsed with strcoll: 1.812446 seconds Time elapsed with strxfrm optimization: 1.101266 seconds Time elapsed with strcoll: 1.813595 seconds Time elapsed with strxfrm optimization: 1.099444 seconds Time elapsed with strcoll: 1.814584 seconds Time elapsed with strxfrm optimization: 1.099542 seconds *****strcoll average: 1.787412 strxfrm average: 1.099523***** Time elapsed with strcoll: 1.820218 seconds Time elapsed with strxfrm optimization: 1.102984 seconds Time elapsed with strcoll: 1.817549 seconds Time elapsed with strxfrm optimization: 1.100526 seconds Time elapsed with strcoll: 1.817020 seconds Time elapsed with strxfrm optimization: 1.099273 seconds Time elapsed with strcoll: 1.820983 seconds Time elapsed with strxfrm optimization: 1.100501 seconds Time elapsed with strcoll: 1.813270 seconds Time elapsed with strxfrm optimization: 1.098904 seconds *****strcoll average: 1.797544 strxfrm average: 1.099828***** Time elapsed with strcoll: 1.815952 seconds Time elapsed with strxfrm optimization: 1.102583 seconds If you'd like to print the contents of the set, there are a couple of lines you can uncomment. It should be straightforward to understand the program, even if you don't know any C++. Note that I still think that the compelling case for strxfrm() caching is sorting tuples, not btree index traversal. All that I ask is that you allow that on the whole, this will pay for the cost of verifying equivalency within _bt_checkkeys() once per index-scan. I am aware that a red-black tree isn't generally an excellent proxy for how a btree will perform, but I don't think that that really matters here. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services
Вложения
В списке pgsql-hackers по дате отправления:
Предыдущее
От: Steve SingerДата:
Сообщение: Re: [PATCH 08/16] Introduce the ApplyCache module which can reassemble transactions from a stream of interspersed changes