On Thu, Apr 13, 2017 at 10:19 PM, Peter Geoghegan <pg@bowt.ie> wrote:
> I actually think Heikki's work here would particularly help on
> spinning rust, especially when less memory is available. He
> specifically justified it on the basis of it resulting in a more
> sequential read pattern, particularly when multiple passes are
> required.
BTW, what you might have missed is that Heikki did end up using a
significant amount of memory in the committed version. It just ended
up being managed by logtape.c, which now does the prereading instead
of tuplesort.c, but at a lower level. There is only one tuple in the
merge heap, but there is still up to 1GB of memory per tape,
containing raw preread tuples mixed with integers that demarcate tape
contents.
--
Peter Geoghegan
VMware vCenter Server
https://www.vmware.com/