Re: Inlining comparators as a performance optimisation
От | Peter Geoghegan |
---|---|
Тема | Re: Inlining comparators as a performance optimisation |
Дата | |
Msg-id | CAEYLb_WH33La4ebVNqgicmba-2CuexDTiS8cj7M5p3NuLRwgew@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Inlining comparators as a performance optimisation (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Inlining comparators as a performance optimisation
|
Список | pgsql-hackers |
On 21 November 2011 22:55, Robert Haas <robertmhaas@gmail.com> wrote: > Results on my machine, for what they're worth: I was curious as to how much of an improvement I'd made to sorting in isolation. I've adding simple sort timing instrumentation to the code in a revised patch, attached, for the convenience of reviewers. This patch adds an int8 specialisation, but it also supports fast path sorting of timestamps by using that same int8 specialisation (for HAVE_INT64_TIMESTAMP builds at least - didn't know if it was worth handling the NaN crud for the other case). ISTM that various different types with identical internal representations can share specialisations like this, which I hope will alleviate some earlier concerns about both the limited applicability of this optimisation and the possible proliferation of specialisations. Here's some raw qsort figures in seconds for the query "select * from orderlines order by test" (where test is a timestamptz column I added and updated with some data, executing repeatedly on the same machine as before): Before: DEBUG: elapsed: 0.031738 DEBUG: elapsed: 0.031595 DEBUG: elapsed: 0.031502 DEBUG: elapsed: 0.031378 DEBUG: elapsed: 0.031359 DEBUG: elapsed: 0.031413 DEBUG: elapsed: 0.031499 DEBUG: elapsed: 0.031394 DEBUG: elapsed: 0.031368 After: DEBUG: elapsed: 0.013341 DEBUG: elapsed: 0.014608 DEBUG: elapsed: 0.013809 DEBUG: elapsed: 0.013244 DEBUG: elapsed: 0.014307 DEBUG: elapsed: 0.013207 DEBUG: elapsed: 0.013227 DEBUG: elapsed: 0.013264 DEBUG: elapsed: 0.013143 DEBUG: elapsed: 0.013455 DEBUG: elapsed: 0.013447 I wonder, is it worth qualifying that the "Sort Method" was a "quicksort (fast path)" sort within explain analyze output? This is a rather large improvement, so It might actually be something that people look out for, as it might be tricky to remember the exact circumstances under which the optimisation kicks in by the time we're done here. I haven't had as much time as I'd like to polish this patch, or to get clearer answers. I expect to spend more time on it over the weekend. -- Peter Geoghegan http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training and Services
Вложения
В списке pgsql-hackers по дате отправления: