On Thu, Feb 16, 2023 at 10:03 AM David Rowley <
dgrowleyml@gmail.com> wrote:
> I suspect it's slower because the final sort must sort the entire
> array still without knowledge that portions of it are pre-sorted. It
> would be very interesting to improve this and do some additional work
> and keep track of the "memtupsortedto" index by pushing them onto a
> List each time we cross the availMem boundary, then do then qsort just
> the final portion of the array in tuplesort_performsort() before doing
> a k-way merge on each segment rather than qsorting the entire thing
> again. I suspect this would be faster when work_mem exceeds L3 by some
> large amount.
Sounds like a reasonable thing to try.
It seems like in-memory merge could still use abbreviation, unlike external merge.
--
John Naylor
EDB:
http://www.enterprisedb.com
