On Wed, Oct 30, 2019 at 9:24 AM Melanie Plageman
<melanieplageman@gmail.com> wrote:
> Checked out the patches a bit and noticed that the tuplesort
> instrumentation uses spaceUsed and I saw this comment in
> tuplesort_get_stats()
> might it be worth trying out the memory accounting API
> 5dd7fc1519461548eebf26c33eac6878ea3e8788 here?
I made exactly the same suggestion several years back, not long after
the API was first proposed by Jeff. However, tuplesort.c has changed a
lot since that time, to the extent that that comment now seems kind of
obsolete. These days, availMem accounting still isn't used at all for
disk sorts. Rather, the slab allocator is used. Virtually all the
memory used to merge is now managed by logtape.c, with only fixed
per-tape memory buffers within tuplesort.c. This per-tape stuff is
tiny anyway -- slightly more than 1KiB per tape.
It would now be relatively straightforward to report the memory used
by disk-based sorts, without needing to use the memory accounting API.
I imagine that it would report the high watermark memory usage during
the final merge. It's possible for this to be lower than the high
watermark during initial run generation (e.g. because of the
MaxAllocSize limit in buffer size within logtape.c), but that still
seems like the most useful figure to users. There'd be a new
"LogicalTapeSetMemory()" function to go along with the existing
LogicalTapeSetBlocks() function, or something along those lines.
Not planning to work on this now, but perhaps you have time for it.
--
Peter Geoghegan