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 по дате отправления: