Re: Re: Using quicksort and a merge step to significantly improve on tuplesort's single run "external sort"
В списке pgsql-hackers по дате отправления:
| От | Andres Freund |
|---|---|
| Тема | Re: Re: Using quicksort and a merge step to significantly improve on tuplesort's single run "external sort" |
| Дата | |
| Msg-id | 20150801135658.GF11473@alap3.anarazel.de обсуждение |
| Ответ на | Re: Re: Using quicksort and a merge step to significantly improve on tuplesort's single run "external sort" (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: Re: Using quicksort and a merge step to significantly
improve on tuplesort's single run "external sort"
|
| Список | pgsql-hackers |
On 2015-07-31 13:31:54 -0400, Robert Haas wrote: > On Fri, Jul 31, 2015 at 7:21 AM, Jeremy Harris <jgh@wizmail.org> wrote: > > Heapification is O(n) already, whether siftup (existing) or down. > > That's not my impression, or what Wikipedia says. Source? Building a binary heap via successive insertions is O(n log n), but building it directly is O(n). Looks like wikipedia agrees too https://en.wikipedia.org/wiki/Binary_heap#Building_a_heap I'm pretty sure that there's a bunch of places where we intentionally build a heap at once instead successively. At least reorderbuffer.c does so, and it looks like nodeMergeAppend as well (that's why they use binaryheap_add_unordered and then binaryheap_build). Greetings, Andres Freund
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера