Re: Insertion Sort Improvements
От | Benjamin Coutu |
---|---|
Тема | Re: Insertion Sort Improvements |
Дата | |
Msg-id | c4a2e53116648187ce0f@zeyos.com обсуждение исходный текст |
Ответ на | Re: Insertion Sort Improvements (John Naylor <john.naylor@enterprisedb.com>) |
Список | pgsql-hackers |
> "Looks like"? I cannot find the reference, but I've read a while back that a well-known company from Redwood uses it for their in-memorycolumnar storage. That might have just been a rumor or might have been research only - not sure. It does not reallymatter anyways. > SortTuples are currently 24 bytes, and supported vector registers are 16 bytes, so not sure how you think that would work. The thought was to logically group multiple sort tuples together and then create a vectorized version of that group withjust the primitive type sort key as well as a small-sized index/offset into that sort group to later swap the correspondingsort tuple referenced by that index/offset. The sorting network would allow us to do branch-less register basedsorting for a particular sort run. I guess this idea is moot, given ... > More broadly, the more invasive a change is, the more risk is involved, and the more effort to test and evaluate. If you'reserious about trying to improve insertion sort performance, the simple idea we discussed at the start of the threadis a much more modest step that has a good chance of justifying the time put into it. That is not to say it's easy,however, because testing is a non-trivial amount of work. I absolutely agree. Let's concentrate on improving things incrementally. Please excuse me wondering given that you have contributed some of the recent vectorization stuff and seeing that you haveobviously experimented a lot with the sort code, that you might already have tried something along those lines or researchedthe subject - it is definitely a very interesting topic. Cheers, Ben
В списке pgsql-hackers по дате отправления: