]> granicus.if.org Git - postgresql/commit
Change the way pre-reading in external sort's merge phase works.
authorHeikki Linnakangas <heikki.linnakangas@iki.fi>
Mon, 3 Oct 2016 10:37:49 +0000 (13:37 +0300)
committerHeikki Linnakangas <heikki.linnakangas@iki.fi>
Mon, 3 Oct 2016 10:37:49 +0000 (13:37 +0300)
commite94568ecc10f2638e542ae34f2990b821bbf90ac
tree7eb7288bc3531f1a3c0d5ee432333e72cbebd844
parente8bdee2770ff52aab208bc6f8965a4a01979d0aa
Change the way pre-reading in external sort's merge phase works.

Don't pre-read tuples into SortTuple slots during merge. Instead, use the
memory for larger read buffers in logtape.c. We're doing the same number
of READTUP() calls either way, but managing the pre-read SortTuple slots
is much more complicated. Also, the on-tape representation is more compact
than SortTuples, so we can fit more pre-read tuples into the same amount
of memory this way. And we have better cache-locality, when we use just a
small number of SortTuple slots.

Now that we only hold one tuple from each tape in the SortTuple slots, we
can greatly simplify the "batch memory" management. We now maintain a
small set of fixed-sized slots, to hold the tuples, and fall back to
palloc() for larger tuples. We use this method during all merge phases,
not just the final merge, and also when randomAccess is requested, and
also in the TSS_SORTEDONTAPE case. In other words, it's used whenever we
do an external sort.

Reviewed by Peter Geoghegan and Claudio Freire.

Discussion: <CAM3SWZTpaORV=yQGVCG8Q4axcZ3MvF-05xe39ZvORdU9JcD6hQ@mail.gmail.com>
src/backend/utils/sort/logtape.c
src/backend/utils/sort/tuplesort.c
src/include/utils/logtape.h