On Sun, Dec 13, 2015 at 7:31 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > The reason for memtuples is to handle random access. Since we are no > longer doing random access, we no longer need it. > > We could free memtuples, re-allocate just enough to form the binary > heap for the N-way merge, and use all the rest of that space (which > could be a significant fraction of work_mem) as part of the new pool.
Oh, you're talking about having the final on-the-fly merge use a tuplestore-style array of pointers to "tuple proper" memory (this was how tuplesort.c worked in all cases about 15 years ago, actually). I thought about that. It's not obvious how we'd do without SortTuple.tupindex during the merge phase, since it sometimes represents an offset into memtuples (the SortTuple array). See "free list" management within mergeonerun(). -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
