On Mon, Feb 3, 2020 at 6:24 PM Jeff Davis <pg...@j-davis.com> wrote: > And now I'm attaching another version of the main Hash Aggregation > patch to be applied on top of the logtape.c patch.
Have you tested this against tuplesort.c, particularly parallel CREATE INDEX? It would be worth trying to measure any performance impact. Note that most parallel CREATE INDEX tuplesorts will do a merge within each worker, and one big merge in the leader. It's much more likely to have multiple passes than a regular serial external sort. Parallel CREATE INDEX is currently accidentally disabled on the master branch. That should be fixed in the next couple of days. You can temporarily revert 74618e77 if you want to get it back for testing purposes today. Have you thought about integer overflow in your heap related routines? This isn't as unlikely as you might think. See commit 512f67c8, for example. Have you thought about the MaxAllocSize restriction as it concerns lts->freeBlocks? Will that be okay when you have many more tapes than before? > Not a lot of changes from the last version; mostly some cleanup and > rebasing. But it's faster now with the logtape.c changes. LogicalTapeSetExtend() seems to work in a way that assumes that the tape is frozen. It would be good to document that assumption, and possible enforce it by way of an assertion. The same remark applies to any other assumptions you're making there. -- Peter Geoghegan
