Re: [PATCH] Incremental sort (was: PoC: Partial sort)
От | Peter Geoghegan |
---|---|
Тема | Re: [PATCH] Incremental sort (was: PoC: Partial sort) |
Дата | |
Msg-id | CAH2-Wz=ptCW_dnRi3z4n8eUCzc82Y2qsd9ReWLr0-nxfhh=Hsg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Incremental sort (was: PoC: Partial sort) (James Coleman <jtc331@gmail.com>) |
Ответы |
Re: [PATCH] Incremental sort (was: PoC: Partial sort)
|
Список | pgsql-hackers |
On Tue, Jun 25, 2019 at 9:53 AM James Coleman <jtc331@gmail.com> wrote: > Given the patch contents I don't see any obviously reason why either > of those possibilities (calling comparetup_heap less often, or it's > cheaper) are likely. Is that something we should investigate further? > Or is it just a nice happy accident that we should ignore since it's > dataset specific? Have you actually confirmed that comparetup_heap() is called less often, by instrumenting the number of individual calls specifically? If there has been a reduction in calls to comparetup_heap(), then that's weird, and needs to be explained. If it turns out that it isn't actually called less often, then I would suggest that the speedup might be related to memory fragmentation, which often matters a lot within tuplesort.c. (This is why external sort merging now uses big buffers, and double buffering.) -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: