On Thu, Feb 6, 2020 at 12:01 AM Heikki Linnakangas <hlinn...@iki.fi> wrote: > It wasn't strictly required for what I was hacking on then. IIRC it > would have saved some memory during sorting, but Peter G felt that it > wasn't worth the trouble, because he made some other changes around the > same time, which made it less important
FWIW, I am not opposed to the patch at all. I would be quite happy to get rid of a bunch of code in tuplesort.c that apparently isn't really necessary anymore (by removing polyphase merge). All I meant back in 2016 was that "pausing" tapes was orthogonal to my own idea of capping the number of tapes that could be used by tuplesort.c. The 500 MAXORDER cap thing hadn't been committed yet when I explained this in the message you linked to, and it wasn't clear if it would ever be committed (Robert committed it about a month afterwards, as it turned out). Capping the size of the merge heap made marginal sorts faster overall, since a more cache efficient merge heap more than made up for having more than one merge pass overall (thanks to numerous optimizations added in 2016, some of which were your work). I also said that the absolute overhead of tapes was not that important back in 2016. Using many tapes within tuplesort.c can never happen anyway (with the 500 MAXORDER cap). Maybe the use of logtape.c by hash aggregate changes the picture there now. Even if it doesn't, I still think that your patch is a good idea. -- Peter Geoghegan
