On Tue, Nov 15, 2016 at 5:31 PM, Robert Haas <robertmh...@gmail.com> wrote: > I think we should develop versions of this that (1) allocate from the > main shared memory segment and (2) allocate from backend-private > memory. Per my previous benchmarking results, allocating from > backend-private memory would be a substantial win for tuplesort.c > because this allocator is substantially more memory-efficient for > large memory contexts than aset.c, and Tomas Vondra tested it out and > found that it is also faster for logical decoding than the approach he > proposed.
The approach that I'd prefer to take with tuplesort.c is to have a buffer for caller tuples that is written to sequentially, and repalloc()'d as needed, much like the memtuples array. It would be slightly tricky to make this work when memtuples needs to be a heap (I'm mostly thinking of top-N heapsorts here). That has perhaps unbeatable efficiency, while also helping cases with significant physical/logical correlation in their input, which is pretty common. Creating an index on a serial PK within pg_restore would probably get notably faster if we went this way. -- 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
