Re: Sort functions with specialized comparators
От | Andrey M. Borodin |
---|---|
Тема | Re: Sort functions with specialized comparators |
Дата | |
Msg-id | D1945B5E-188C-4C83-8AA0-2D0F80248403@yandex-team.ru обсуждение исходный текст |
Ответ на | Re: Sort functions with specialized comparators (John Naylor <johncnaylorls@gmail.com>) |
Ответы |
Sort functions with specialized comparators
|
Список | pgsql-hackers |
> On 7 Jan 2025, at 09:43, John Naylor <johncnaylorls@gmail.com> wrote: > >> With the same setup as in the first message of this thread we can do: >> >> postgres=# SELECT _int_contains(arr,ARRAY[1]) FROM arrays_to_sort; >> >> before patch patch >> Time: 567.928 ms >> after patch >> Time: 890.297 ms >> timing of this function is dominated by PREPAREARR(a); >> >> What bothers me is that PREPAREARR(a); is returning new array in case of empty input. That's why I considered little refactoringof resize_intArrayType(): reorder cases so that if (num == ARRNELEMS(a)) was first. > > Hmm, I'm confused. First, none of the arrays are empty that I can see > -- am I missing something? Ugh...sorry, I posted very confusing results. For starters, I swapped "patched" and "unpatched" results. So results showclear improvement in default case. I'm worried about another case that we cannot measure: PREPAREARR(a) on empty array will return new array. And one more case. BTW for pre-sorted desc arrays desc sorting is slower: postgres=# CREATE TABLE arrays_sorted_desc AS SELECT a arr FROM (SELECT ARRAY(SELECT -i from generate_series(1, 1000000)i) a), generate_series(1, 10); SELECT 10 Time: 707.016 ms postgres=# SELECT (sort_desc(arr))[0] FROM arrays_sorted_desc; Time: 41.874 ms but with a patch postgres=# SELECT (sort_desc(arr))[0] FROM arrays_sorted_desc; Time: 166.837 ms Best regards, Andrey Borodin.
В списке pgsql-hackers по дате отправления: