On Tue, Jun 25, 2019 at 1:13 PM Peter Geoghegan <pg@bowt.ie> wrote:
>
> 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.)
No, I haven't confirmed that it's called less frequently, and I'd be
extremely surprised if it were given the diff doesn't suggest any
changes to that at all.
If you think it's important enough to do so, I can instrument it to
confirm, but I was mostly wanting to know if there were any other
plausible explanations, and I think you've provided one: there *are*
changes in the patch to memory contexts in tuplesort.c, so if memory
fragmentation is a real concern this patch could definitely notice
changes in that regard.
James Coleman