1999-10-16 19:49:28 +00:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
|
|
|
* logtape.c
|
|
|
|
* Management of "logical tapes" within temporary files.
|
|
|
|
*
|
|
|
|
* This module exists to support sorting via multiple merge passes (see
|
1999-10-17 22:15:09 +00:00
|
|
|
* tuplesort.c). Merging is an ideal algorithm for tape devices, but if
|
|
|
|
* we implement it on disk by creating a separate file for each "tape",
|
1999-10-16 19:49:28 +00:00
|
|
|
* there is an annoying problem: the peak space usage is at least twice
|
2014-05-06 12:12:18 -04:00
|
|
|
* the volume of actual data to be sorted. (This must be so because each
|
1999-10-16 19:49:28 +00:00
|
|
|
* datum will appear in both the input and output tapes of the final
|
2014-05-06 12:12:18 -04:00
|
|
|
* merge pass. For seven-tape polyphase merge, which is otherwise a
|
1999-10-16 19:49:28 +00:00
|
|
|
* pretty good algorithm, peak usage is more like 4x actual data volume.)
|
|
|
|
*
|
|
|
|
* We can work around this problem by recognizing that any one tape
|
|
|
|
* dataset (with the possible exception of the final output) is written
|
2014-05-06 12:12:18 -04:00
|
|
|
* and read exactly once in a perfectly sequential manner. Therefore,
|
1999-10-16 19:49:28 +00:00
|
|
|
* a datum once read will not be required again, and we can recycle its
|
|
|
|
* space for use by the new tape dataset(s) being generated. In this way,
|
|
|
|
* the total space usage is essentially just the actual data volume, plus
|
|
|
|
* insignificant bookkeeping and start/stop overhead.
|
|
|
|
*
|
|
|
|
* Few OSes allow arbitrary parts of a file to be released back to the OS,
|
|
|
|
* so we have to implement this space-recycling ourselves within a single
|
|
|
|
* logical file. logtape.c exists to perform this bookkeeping and provide
|
1999-10-17 22:15:09 +00:00
|
|
|
* the illusion of N independent tape devices to tuplesort.c. Note that
|
1999-10-16 19:49:28 +00:00
|
|
|
* logtape.c itself depends on buffile.c to provide a "logical file" of
|
|
|
|
* larger size than the underlying OS may support.
|
|
|
|
*
|
|
|
|
* For simplicity, we allocate and release space in the underlying file
|
|
|
|
* in BLCKSZ-size blocks. Space allocation boils down to keeping track
|
|
|
|
* of which blocks in the underlying file belong to which logical tape,
|
2006-03-07 23:46:24 +00:00
|
|
|
* plus any blocks that are free (recycled and not yet reused).
|
1999-10-16 19:49:28 +00:00
|
|
|
* The blocks in each logical tape are remembered using a method borrowed
|
|
|
|
* from the Unix HFS filesystem: we store data block numbers in an
|
|
|
|
* "indirect block". If an indirect block fills up, we write it out to
|
|
|
|
* the underlying file and remember its location in a second-level indirect
|
|
|
|
* block. In the same way second-level blocks are remembered in third-
|
|
|
|
* level blocks, and so on if necessary (of course we're talking huge
|
|
|
|
* amounts of data here). The topmost indirect block of a given logical
|
|
|
|
* tape is never actually written out to the physical file, but all lower-
|
|
|
|
* level indirect blocks will be.
|
|
|
|
*
|
|
|
|
* The initial write pass is guaranteed to fill the underlying file
|
|
|
|
* perfectly sequentially, no matter how data is divided into logical tapes.
|
|
|
|
* Once we begin merge passes, the access pattern becomes considerably
|
|
|
|
* less predictable --- but the seeking involved should be comparable to
|
|
|
|
* what would happen if we kept each logical tape in a separate file,
|
|
|
|
* so there's no serious performance penalty paid to obtain the space
|
|
|
|
* savings of recycling. We try to localize the write accesses by always
|
|
|
|
* writing to the lowest-numbered free block when we have a choice; it's
|
|
|
|
* not clear this helps much, but it can't hurt. (XXX perhaps a LIFO
|
|
|
|
* policy for free blocks would be better?)
|
|
|
|
*
|
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>
2016-10-03 13:37:49 +03:00
|
|
|
* To further make the I/Os more sequential, we can use a larger buffer
|
|
|
|
* when reading, and read multiple blocks from the same tape in one go,
|
|
|
|
* whenever the buffer becomes empty. LogicalTapeAssignReadBufferSize()
|
|
|
|
* can be used to set the size of the read buffer.
|
|
|
|
*
|
2006-03-07 23:46:24 +00:00
|
|
|
* To support the above policy of writing to the lowest free block,
|
|
|
|
* ltsGetFreeBlock sorts the list of free block numbers into decreasing
|
|
|
|
* order each time it is asked for a block and the list isn't currently
|
2014-05-06 12:12:18 -04:00
|
|
|
* sorted. This is an efficient way to handle it because we expect cycles
|
2006-03-07 23:46:24 +00:00
|
|
|
* of releasing many blocks followed by re-using many blocks, due to
|
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>
2016-10-03 13:37:49 +03:00
|
|
|
* the larger read buffer.
|
2006-03-07 23:46:24 +00:00
|
|
|
*
|
1999-10-16 19:49:28 +00:00
|
|
|
* Since all the bookkeeping and buffer memory is allocated with palloc(),
|
|
|
|
* and the underlying file(s) are made with OpenTemporaryFile, all resources
|
|
|
|
* for a logical tape set are certain to be cleaned up even if processing
|
2003-07-25 20:18:01 +00:00
|
|
|
* is aborted by ereport(ERROR). To avoid confusion, the caller should take
|
1999-10-16 19:49:28 +00:00
|
|
|
* care that all calls for a single LogicalTapeSet are made in the same
|
|
|
|
* palloc context.
|
2000-04-12 17:17:23 +00:00
|
|
|
*
|
2016-01-02 13:33:40 -05:00
|
|
|
* Portions Copyright (c) 1996-2016, PostgreSQL Global Development Group
|
2000-01-26 05:58:53 +00:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1999-10-16 19:49:28 +00:00
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/backend/utils/sort/logtape.c
|
1999-10-16 19:49:28 +00:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "postgres.h"
|
|
|
|
|
|
|
|
#include "storage/buffile.h"
|
|
|
|
#include "utils/logtape.h"
|
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>
2016-10-03 13:37:49 +03:00
|
|
|
#include "utils/memutils.h"
|
1999-10-16 19:49:28 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Block indexes are "long"s, so we can fit this many per indirect block.
|
|
|
|
* NB: we assume this is an exact fit!
|
|
|
|
*/
|
2000-04-12 17:17:23 +00:00
|
|
|
#define BLOCKS_PER_INDIR_BLOCK ((int) (BLCKSZ / sizeof(long)))
|
1999-10-16 19:49:28 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We use a struct like this for each active indirection level of each
|
|
|
|
* logical tape. If the indirect block is not the highest level of its
|
|
|
|
* tape, the "nextup" link points to the next higher level. Only the
|
|
|
|
* "ptrs" array is written out if we have to dump the indirect block to
|
|
|
|
* disk. If "ptrs" is not completely full, we store -1L in the first
|
|
|
|
* unused slot at completion of the write phase for the logical tape.
|
|
|
|
*/
|
|
|
|
typedef struct IndirectBlock
|
|
|
|
{
|
|
|
|
int nextSlot; /* next pointer slot to write or read */
|
2005-10-15 02:49:52 +00:00
|
|
|
struct IndirectBlock *nextup; /* parent indirect level, or NULL if
|
|
|
|
* top */
|
|
|
|
long ptrs[BLOCKS_PER_INDIR_BLOCK]; /* indexes of contained blocks */
|
1999-10-16 19:49:28 +00:00
|
|
|
} IndirectBlock;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This data structure represents a single "logical tape" within the set
|
|
|
|
* of logical tapes stored in the same file. We must keep track of the
|
|
|
|
* current partially-read-or-written data block as well as the active
|
|
|
|
* indirect block level(s).
|
|
|
|
*/
|
|
|
|
typedef struct LogicalTape
|
|
|
|
{
|
|
|
|
IndirectBlock *indirect; /* bottom of my indirect-block hierarchy */
|
|
|
|
bool writing; /* T while in write phase */
|
2005-10-15 02:49:52 +00:00
|
|
|
bool frozen; /* T if blocks should not be freed when read */
|
1999-10-16 19:49:28 +00:00
|
|
|
bool dirty; /* does buffer need to be written? */
|
2000-04-12 17:17:23 +00:00
|
|
|
|
1999-10-16 19:49:28 +00:00
|
|
|
/*
|
2005-10-15 02:49:52 +00:00
|
|
|
* The total data volume in the logical tape is numFullBlocks * BLCKSZ +
|
2014-05-06 12:12:18 -04:00
|
|
|
* lastBlockBytes. BUT: we do not update lastBlockBytes during writing,
|
2005-10-15 02:49:52 +00:00
|
|
|
* only at completion of a write phase.
|
1999-10-16 19:49:28 +00:00
|
|
|
*/
|
|
|
|
long numFullBlocks; /* number of complete blocks in log tape */
|
2000-04-12 17:17:23 +00:00
|
|
|
int lastBlockBytes; /* valid bytes in last (incomplete) block */
|
|
|
|
|
1999-10-16 19:49:28 +00:00
|
|
|
/*
|
|
|
|
* Buffer for current data block. Note we don't bother to store the
|
2005-10-15 02:49:52 +00:00
|
|
|
* actual file block number of the data block (during the write phase it
|
|
|
|
* hasn't been assigned yet, and during read we don't care anymore). But
|
|
|
|
* we do need the relative block number so we can detect end-of-tape while
|
|
|
|
* reading.
|
1999-10-16 19:49:28 +00:00
|
|
|
*/
|
2006-02-19 05:58:36 +00:00
|
|
|
char *buffer; /* physical buffer (separately palloc'd) */
|
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>
2016-10-03 13:37:49 +03:00
|
|
|
int buffer_size; /* allocated size of the buffer */
|
2000-04-12 17:17:23 +00:00
|
|
|
long curBlockNumber; /* this block's logical blk# within tape */
|
1999-10-16 19:49:28 +00:00
|
|
|
int pos; /* next read/write position in buffer */
|
|
|
|
int nbytes; /* total # of valid bytes in buffer */
|
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>
2016-10-03 13:37:49 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Desired buffer size to use when reading. To keep things simple, we use
|
|
|
|
* a single-block buffer when writing, or when reading a frozen tape. But
|
|
|
|
* when we are reading and will only read forwards, we allocate a larger
|
|
|
|
* buffer, determined by read_buffer_size.
|
|
|
|
*/
|
|
|
|
int read_buffer_size;
|
1999-10-16 19:49:28 +00:00
|
|
|
} LogicalTape;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This data structure represents a set of related "logical tapes" sharing
|
|
|
|
* space in a single underlying file. (But that "file" may be multiple files
|
|
|
|
* if needed to escape OS limits on file size; buffile.c handles that for us.)
|
|
|
|
* The number of tapes is fixed at creation.
|
|
|
|
*/
|
|
|
|
struct LogicalTapeSet
|
|
|
|
{
|
2000-04-12 17:17:23 +00:00
|
|
|
BufFile *pfile; /* underlying file for whole tape set */
|
1999-10-16 19:49:28 +00:00
|
|
|
long nFileBlocks; /* # of blocks used in underlying file */
|
2000-04-12 17:17:23 +00:00
|
|
|
|
1999-10-16 19:49:28 +00:00
|
|
|
/*
|
2005-10-15 02:49:52 +00:00
|
|
|
* We store the numbers of recycled-and-available blocks in freeBlocks[].
|
2006-03-07 23:46:24 +00:00
|
|
|
* When there are no such blocks, we extend the underlying file.
|
2006-03-07 19:06:50 +00:00
|
|
|
*
|
|
|
|
* If forgetFreeSpace is true then any freed blocks are simply forgotten
|
|
|
|
* rather than being remembered in freeBlocks[]. See notes for
|
|
|
|
* LogicalTapeSetForgetFreeSpace().
|
2006-03-07 23:46:24 +00:00
|
|
|
*
|
|
|
|
* If blocksSorted is true then the block numbers in freeBlocks are in
|
|
|
|
* *decreasing* order, so that removing the last entry gives us the lowest
|
2014-05-06 12:12:18 -04:00
|
|
|
* free block. We re-sort the blocks whenever a block is demanded; this
|
2006-03-07 23:46:24 +00:00
|
|
|
* should be reasonably efficient given the expected usage pattern.
|
1999-10-16 19:49:28 +00:00
|
|
|
*/
|
2006-03-07 19:06:50 +00:00
|
|
|
bool forgetFreeSpace; /* are we remembering free blocks? */
|
2006-03-07 23:46:24 +00:00
|
|
|
bool blocksSorted; /* is freeBlocks[] currently in order? */
|
1999-10-16 19:49:28 +00:00
|
|
|
long *freeBlocks; /* resizable array */
|
|
|
|
int nFreeBlocks; /* # of currently free blocks */
|
2005-10-15 02:49:52 +00:00
|
|
|
int freeBlocksLen; /* current allocated length of freeBlocks[] */
|
2000-04-12 17:17:23 +00:00
|
|
|
|
2015-02-21 16:12:14 -05:00
|
|
|
/* The array of logical tapes. */
|
1999-10-16 19:49:28 +00:00
|
|
|
int nTapes; /* # of logical tapes in set */
|
2015-02-21 16:12:14 -05:00
|
|
|
LogicalTape tapes[FLEXIBLE_ARRAY_MEMBER]; /* has nTapes nentries */
|
1999-10-16 19:49:28 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
static void ltsWriteBlock(LogicalTapeSet *lts, long blocknum, void *buffer);
|
|
|
|
static void ltsReadBlock(LogicalTapeSet *lts, long blocknum, void *buffer);
|
|
|
|
static long ltsGetFreeBlock(LogicalTapeSet *lts);
|
|
|
|
static void ltsReleaseBlock(LogicalTapeSet *lts, long blocknum);
|
|
|
|
static void ltsRecordBlockNum(LogicalTapeSet *lts, IndirectBlock *indirect,
|
2000-04-12 17:17:23 +00:00
|
|
|
long blocknum);
|
1999-10-16 19:49:28 +00:00
|
|
|
static long ltsRewindIndirectBlock(LogicalTapeSet *lts,
|
2000-04-12 17:17:23 +00:00
|
|
|
IndirectBlock *indirect,
|
|
|
|
bool freezing);
|
1999-10-16 19:49:28 +00:00
|
|
|
static long ltsRewindFrozenIndirectBlock(LogicalTapeSet *lts,
|
2000-04-12 17:17:23 +00:00
|
|
|
IndirectBlock *indirect);
|
1999-10-16 19:49:28 +00:00
|
|
|
static long ltsRecallNextBlockNum(LogicalTapeSet *lts,
|
2000-04-12 17:17:23 +00:00
|
|
|
IndirectBlock *indirect,
|
|
|
|
bool frozen);
|
1999-10-16 19:49:28 +00:00
|
|
|
static long ltsRecallPrevBlockNum(LogicalTapeSet *lts,
|
2000-04-12 17:17:23 +00:00
|
|
|
IndirectBlock *indirect);
|
1999-10-16 19:49:28 +00:00
|
|
|
static void ltsDumpBuffer(LogicalTapeSet *lts, LogicalTape *lt);
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Write a block-sized buffer to the specified block of the underlying file.
|
|
|
|
*
|
|
|
|
* NB: should not attempt to write beyond current end of file (ie, create
|
|
|
|
* "holes" in file), since BufFile doesn't allow that. The first write pass
|
|
|
|
* must write blocks sequentially.
|
|
|
|
*
|
2003-07-25 20:18:01 +00:00
|
|
|
* No need for an error return convention; we ereport() on any error.
|
1999-10-16 19:49:28 +00:00
|
|
|
*/
|
|
|
|
static void
|
|
|
|
ltsWriteBlock(LogicalTapeSet *lts, long blocknum, void *buffer)
|
|
|
|
{
|
|
|
|
if (BufFileSeekBlock(lts->pfile, blocknum) != 0 ||
|
|
|
|
BufFileWrite(lts->pfile, buffer, BLCKSZ) != BLCKSZ)
|
2003-07-25 20:18:01 +00:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode_for_file_access(),
|
|
|
|
errmsg("could not write block %ld of temporary file: %m",
|
2014-06-12 18:59:06 -04:00
|
|
|
blocknum)));
|
1999-10-16 19:49:28 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Read a block-sized buffer from the specified block of the underlying file.
|
|
|
|
*
|
2014-05-06 12:12:18 -04:00
|
|
|
* No need for an error return convention; we ereport() on any error. This
|
1999-10-16 19:49:28 +00:00
|
|
|
* module should never attempt to read a block it doesn't know is there.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
ltsReadBlock(LogicalTapeSet *lts, long blocknum, void *buffer)
|
|
|
|
{
|
|
|
|
if (BufFileSeekBlock(lts->pfile, blocknum) != 0 ||
|
|
|
|
BufFileRead(lts->pfile, buffer, BLCKSZ) != BLCKSZ)
|
2003-07-25 20:18:01 +00:00
|
|
|
ereport(ERROR,
|
|
|
|
(errcode_for_file_access(),
|
|
|
|
errmsg("could not read block %ld of temporary file: %m",
|
|
|
|
blocknum)));
|
1999-10-16 19:49:28 +00:00
|
|
|
}
|
|
|
|
|
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>
2016-10-03 13:37:49 +03:00
|
|
|
/*
|
|
|
|
* Read as many blocks as we can into the per-tape buffer.
|
|
|
|
*
|
|
|
|
* The caller can specify the next physical block number to read, in
|
|
|
|
* datablocknum, or -1 to fetch the next block number from the internal block.
|
|
|
|
* If datablocknum == -1, the caller must've already set curBlockNumber.
|
|
|
|
*
|
|
|
|
* Returns true if anything was read, 'false' on EOF.
|
|
|
|
*/
|
|
|
|
static bool
|
|
|
|
ltsReadFillBuffer(LogicalTapeSet *lts, LogicalTape *lt, long datablocknum)
|
|
|
|
{
|
|
|
|
lt->pos = 0;
|
|
|
|
lt->nbytes = 0;
|
|
|
|
|
|
|
|
do
|
|
|
|
{
|
|
|
|
/* Fetch next block number (unless provided by caller) */
|
|
|
|
if (datablocknum == -1)
|
|
|
|
{
|
|
|
|
datablocknum = ltsRecallNextBlockNum(lts, lt->indirect, lt->frozen);
|
|
|
|
if (datablocknum == -1L)
|
|
|
|
break; /* EOF */
|
|
|
|
lt->curBlockNumber++;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Read the block */
|
|
|
|
ltsReadBlock(lts, datablocknum, (void *) (lt->buffer + lt->nbytes));
|
|
|
|
if (!lt->frozen)
|
|
|
|
ltsReleaseBlock(lts, datablocknum);
|
|
|
|
|
|
|
|
if (lt->curBlockNumber < lt->numFullBlocks)
|
|
|
|
lt->nbytes += BLCKSZ;
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* EOF */
|
|
|
|
lt->nbytes += lt->lastBlockBytes;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Advance to next block, if we have buffer space left */
|
|
|
|
datablocknum = -1;
|
|
|
|
} while (lt->nbytes < lt->buffer_size);
|
|
|
|
|
|
|
|
return (lt->nbytes > 0);
|
|
|
|
}
|
|
|
|
|
2006-03-07 23:46:24 +00:00
|
|
|
/*
|
|
|
|
* qsort comparator for sorting freeBlocks[] into decreasing order.
|
|
|
|
*/
|
|
|
|
static int
|
|
|
|
freeBlocks_cmp(const void *a, const void *b)
|
|
|
|
{
|
|
|
|
long ablk = *((const long *) a);
|
|
|
|
long bblk = *((const long *) b);
|
|
|
|
|
|
|
|
/* can't just subtract because long might be wider than int */
|
|
|
|
if (ablk < bblk)
|
|
|
|
return 1;
|
|
|
|
if (ablk > bblk)
|
|
|
|
return -1;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
1999-10-16 19:49:28 +00:00
|
|
|
/*
|
|
|
|
* Select a currently unused block for writing to.
|
|
|
|
*
|
|
|
|
* NB: should only be called when writer is ready to write immediately,
|
|
|
|
* to ensure that first write pass is sequential.
|
|
|
|
*/
|
|
|
|
static long
|
|
|
|
ltsGetFreeBlock(LogicalTapeSet *lts)
|
|
|
|
{
|
2000-04-12 17:17:23 +00:00
|
|
|
/*
|
2005-10-15 02:49:52 +00:00
|
|
|
* If there are multiple free blocks, we select the one appearing last in
|
2006-03-07 23:46:24 +00:00
|
|
|
* freeBlocks[] (after sorting the array if needed). If there are none,
|
|
|
|
* assign the next block at the end of the file.
|
1999-10-16 19:49:28 +00:00
|
|
|
*/
|
|
|
|
if (lts->nFreeBlocks > 0)
|
2006-03-07 23:46:24 +00:00
|
|
|
{
|
|
|
|
if (!lts->blocksSorted)
|
|
|
|
{
|
|
|
|
qsort((void *) lts->freeBlocks, lts->nFreeBlocks,
|
|
|
|
sizeof(long), freeBlocks_cmp);
|
|
|
|
lts->blocksSorted = true;
|
|
|
|
}
|
1999-10-16 19:49:28 +00:00
|
|
|
return lts->freeBlocks[--lts->nFreeBlocks];
|
2006-03-07 23:46:24 +00:00
|
|
|
}
|
1999-10-16 19:49:28 +00:00
|
|
|
else
|
|
|
|
return lts->nFileBlocks++;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Return a block# to the freelist.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
ltsReleaseBlock(LogicalTapeSet *lts, long blocknum)
|
|
|
|
{
|
2000-04-12 17:17:23 +00:00
|
|
|
int ndx;
|
1999-10-16 19:49:28 +00:00
|
|
|
|
2006-03-07 19:06:50 +00:00
|
|
|
/*
|
|
|
|
* Do nothing if we're no longer interested in remembering free space.
|
|
|
|
*/
|
|
|
|
if (lts->forgetFreeSpace)
|
|
|
|
return;
|
|
|
|
|
1999-10-16 19:49:28 +00:00
|
|
|
/*
|
|
|
|
* Enlarge freeBlocks array if full.
|
|
|
|
*/
|
|
|
|
if (lts->nFreeBlocks >= lts->freeBlocksLen)
|
|
|
|
{
|
|
|
|
lts->freeBlocksLen *= 2;
|
|
|
|
lts->freeBlocks = (long *) repalloc(lts->freeBlocks,
|
2005-10-15 02:49:52 +00:00
|
|
|
lts->freeBlocksLen * sizeof(long));
|
1999-10-16 19:49:28 +00:00
|
|
|
}
|
2000-04-12 17:17:23 +00:00
|
|
|
|
1999-10-16 19:49:28 +00:00
|
|
|
/*
|
2006-10-04 00:30:14 +00:00
|
|
|
* Add blocknum to array, and mark the array unsorted if it's no longer in
|
|
|
|
* decreasing order.
|
1999-10-16 19:49:28 +00:00
|
|
|
*/
|
|
|
|
ndx = lts->nFreeBlocks++;
|
2006-03-07 23:46:24 +00:00
|
|
|
lts->freeBlocks[ndx] = blocknum;
|
2006-10-04 00:30:14 +00:00
|
|
|
if (ndx > 0 && lts->freeBlocks[ndx - 1] < blocknum)
|
2006-03-07 23:46:24 +00:00
|
|
|
lts->blocksSorted = false;
|
1999-10-16 19:49:28 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* These routines manipulate indirect-block hierarchies. All are recursive
|
|
|
|
* so that they don't have any specific limit on the depth of hierarchy.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Record a data block number in a logical tape's lowest indirect block,
|
|
|
|
* or record an indirect block's number in the next higher indirect level.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
ltsRecordBlockNum(LogicalTapeSet *lts, IndirectBlock *indirect,
|
|
|
|
long blocknum)
|
|
|
|
{
|
|
|
|
if (indirect->nextSlot >= BLOCKS_PER_INDIR_BLOCK)
|
|
|
|
{
|
|
|
|
/*
|
2005-10-15 02:49:52 +00:00
|
|
|
* This indirect block is full, so dump it out and recursively save
|
|
|
|
* its address in the next indirection level. Create a new
|
2000-04-12 17:17:23 +00:00
|
|
|
* indirection level if there wasn't one before.
|
1999-10-16 19:49:28 +00:00
|
|
|
*/
|
2000-04-12 17:17:23 +00:00
|
|
|
long indirblock = ltsGetFreeBlock(lts);
|
1999-10-16 19:49:28 +00:00
|
|
|
|
|
|
|
ltsWriteBlock(lts, indirblock, (void *) indirect->ptrs);
|
|
|
|
if (indirect->nextup == NULL)
|
|
|
|
{
|
|
|
|
indirect->nextup = (IndirectBlock *) palloc(sizeof(IndirectBlock));
|
|
|
|
indirect->nextup->nextSlot = 0;
|
|
|
|
indirect->nextup->nextup = NULL;
|
|
|
|
}
|
|
|
|
ltsRecordBlockNum(lts, indirect->nextup, indirblock);
|
2000-04-12 17:17:23 +00:00
|
|
|
|
1999-10-16 19:49:28 +00:00
|
|
|
/*
|
|
|
|
* Reset to fill another indirect block at this level.
|
|
|
|
*/
|
|
|
|
indirect->nextSlot = 0;
|
|
|
|
}
|
|
|
|
indirect->ptrs[indirect->nextSlot++] = blocknum;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Reset a logical tape's indirect-block hierarchy after a write pass
|
2014-05-06 12:12:18 -04:00
|
|
|
* to prepare for reading. We dump out partly-filled blocks except
|
1999-10-16 19:49:28 +00:00
|
|
|
* at the top of the hierarchy, and we rewind each level to the start.
|
|
|
|
* This call returns the first data block number, or -1L if the tape
|
|
|
|
* is empty.
|
|
|
|
*
|
|
|
|
* Unless 'freezing' is true, release indirect blocks to the free pool after
|
|
|
|
* reading them.
|
|
|
|
*/
|
|
|
|
static long
|
|
|
|
ltsRewindIndirectBlock(LogicalTapeSet *lts,
|
|
|
|
IndirectBlock *indirect,
|
|
|
|
bool freezing)
|
|
|
|
{
|
2006-02-19 05:58:36 +00:00
|
|
|
/* Handle case of never-written-to tape */
|
|
|
|
if (indirect == NULL)
|
|
|
|
return -1L;
|
|
|
|
|
1999-10-16 19:49:28 +00:00
|
|
|
/* Insert sentinel if block is not full */
|
|
|
|
if (indirect->nextSlot < BLOCKS_PER_INDIR_BLOCK)
|
|
|
|
indirect->ptrs[indirect->nextSlot] = -1L;
|
2000-04-12 17:17:23 +00:00
|
|
|
|
1999-10-16 19:49:28 +00:00
|
|
|
/*
|
2005-10-15 02:49:52 +00:00
|
|
|
* If block is not topmost, write it out, and recurse to obtain address of
|
|
|
|
* first block in this hierarchy level. Read that one in.
|
1999-10-16 19:49:28 +00:00
|
|
|
*/
|
|
|
|
if (indirect->nextup != NULL)
|
|
|
|
{
|
2000-04-12 17:17:23 +00:00
|
|
|
long indirblock = ltsGetFreeBlock(lts);
|
1999-10-16 19:49:28 +00:00
|
|
|
|
|
|
|
ltsWriteBlock(lts, indirblock, (void *) indirect->ptrs);
|
|
|
|
ltsRecordBlockNum(lts, indirect->nextup, indirblock);
|
|
|
|
indirblock = ltsRewindIndirectBlock(lts, indirect->nextup, freezing);
|
|
|
|
Assert(indirblock != -1L);
|
|
|
|
ltsReadBlock(lts, indirblock, (void *) indirect->ptrs);
|
2000-04-12 17:17:23 +00:00
|
|
|
if (!freezing)
|
1999-10-16 19:49:28 +00:00
|
|
|
ltsReleaseBlock(lts, indirblock);
|
|
|
|
}
|
2000-04-12 17:17:23 +00:00
|
|
|
|
1999-10-16 19:49:28 +00:00
|
|
|
/*
|
|
|
|
* Reset my next-block pointer, and then fetch a block number if any.
|
|
|
|
*/
|
|
|
|
indirect->nextSlot = 0;
|
|
|
|
if (indirect->ptrs[0] == -1L)
|
|
|
|
return -1L;
|
|
|
|
return indirect->ptrs[indirect->nextSlot++];
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Rewind a previously-frozen indirect-block hierarchy for another read pass.
|
|
|
|
* This call returns the first data block number, or -1L if the tape
|
|
|
|
* is empty.
|
|
|
|
*/
|
|
|
|
static long
|
|
|
|
ltsRewindFrozenIndirectBlock(LogicalTapeSet *lts,
|
|
|
|
IndirectBlock *indirect)
|
|
|
|
{
|
2006-02-19 05:58:36 +00:00
|
|
|
/* Handle case of never-written-to tape */
|
|
|
|
if (indirect == NULL)
|
|
|
|
return -1L;
|
|
|
|
|
1999-10-16 19:49:28 +00:00
|
|
|
/*
|
2005-10-15 02:49:52 +00:00
|
|
|
* If block is not topmost, recurse to obtain address of first block in
|
|
|
|
* this hierarchy level. Read that one in.
|
1999-10-16 19:49:28 +00:00
|
|
|
*/
|
|
|
|
if (indirect->nextup != NULL)
|
|
|
|
{
|
2000-04-12 17:17:23 +00:00
|
|
|
long indirblock;
|
1999-10-16 19:49:28 +00:00
|
|
|
|
|
|
|
indirblock = ltsRewindFrozenIndirectBlock(lts, indirect->nextup);
|
|
|
|
Assert(indirblock != -1L);
|
|
|
|
ltsReadBlock(lts, indirblock, (void *) indirect->ptrs);
|
|
|
|
}
|
2000-04-12 17:17:23 +00:00
|
|
|
|
1999-10-16 19:49:28 +00:00
|
|
|
/*
|
|
|
|
* Reset my next-block pointer, and then fetch a block number if any.
|
|
|
|
*/
|
|
|
|
indirect->nextSlot = 0;
|
|
|
|
if (indirect->ptrs[0] == -1L)
|
|
|
|
return -1L;
|
|
|
|
return indirect->ptrs[indirect->nextSlot++];
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Obtain next data block number in the forward direction, or -1L if no more.
|
|
|
|
*
|
|
|
|
* Unless 'frozen' is true, release indirect blocks to the free pool after
|
|
|
|
* reading them.
|
|
|
|
*/
|
|
|
|
static long
|
|
|
|
ltsRecallNextBlockNum(LogicalTapeSet *lts,
|
|
|
|
IndirectBlock *indirect,
|
|
|
|
bool frozen)
|
|
|
|
{
|
2006-02-19 05:58:36 +00:00
|
|
|
/* Handle case of never-written-to tape */
|
|
|
|
if (indirect == NULL)
|
|
|
|
return -1L;
|
|
|
|
|
1999-10-16 19:49:28 +00:00
|
|
|
if (indirect->nextSlot >= BLOCKS_PER_INDIR_BLOCK ||
|
|
|
|
indirect->ptrs[indirect->nextSlot] == -1L)
|
|
|
|
{
|
2000-04-12 17:17:23 +00:00
|
|
|
long indirblock;
|
1999-10-16 19:49:28 +00:00
|
|
|
|
|
|
|
if (indirect->nextup == NULL)
|
|
|
|
return -1L; /* nothing left at this level */
|
|
|
|
indirblock = ltsRecallNextBlockNum(lts, indirect->nextup, frozen);
|
|
|
|
if (indirblock == -1L)
|
|
|
|
return -1L; /* nothing left at this level */
|
|
|
|
ltsReadBlock(lts, indirblock, (void *) indirect->ptrs);
|
2000-04-12 17:17:23 +00:00
|
|
|
if (!frozen)
|
1999-10-16 19:49:28 +00:00
|
|
|
ltsReleaseBlock(lts, indirblock);
|
|
|
|
indirect->nextSlot = 0;
|
|
|
|
}
|
|
|
|
if (indirect->ptrs[indirect->nextSlot] == -1L)
|
|
|
|
return -1L;
|
|
|
|
return indirect->ptrs[indirect->nextSlot++];
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Obtain next data block number in the reverse direction, or -1L if no more.
|
|
|
|
*
|
|
|
|
* Note this fetches the block# before the one last returned, no matter which
|
|
|
|
* direction of call returned that one. If we fail, no change in state.
|
|
|
|
*
|
|
|
|
* This routine can only be used in 'frozen' state, so there's no need to
|
|
|
|
* pass a parameter telling whether to release blocks ... we never do.
|
|
|
|
*/
|
|
|
|
static long
|
|
|
|
ltsRecallPrevBlockNum(LogicalTapeSet *lts,
|
|
|
|
IndirectBlock *indirect)
|
|
|
|
{
|
2006-02-19 05:58:36 +00:00
|
|
|
/* Handle case of never-written-to tape */
|
|
|
|
if (indirect == NULL)
|
|
|
|
return -1L;
|
|
|
|
|
1999-10-16 19:49:28 +00:00
|
|
|
if (indirect->nextSlot <= 1)
|
|
|
|
{
|
2000-04-12 17:17:23 +00:00
|
|
|
long indirblock;
|
1999-10-16 19:49:28 +00:00
|
|
|
|
|
|
|
if (indirect->nextup == NULL)
|
|
|
|
return -1L; /* nothing left at this level */
|
|
|
|
indirblock = ltsRecallPrevBlockNum(lts, indirect->nextup);
|
|
|
|
if (indirblock == -1L)
|
|
|
|
return -1L; /* nothing left at this level */
|
|
|
|
ltsReadBlock(lts, indirblock, (void *) indirect->ptrs);
|
2000-04-12 17:17:23 +00:00
|
|
|
|
|
|
|
/*
|
2005-10-15 02:49:52 +00:00
|
|
|
* The previous block would only have been written out if full, so we
|
|
|
|
* need not search it for a -1 sentinel.
|
1999-10-16 19:49:28 +00:00
|
|
|
*/
|
2000-04-12 17:17:23 +00:00
|
|
|
indirect->nextSlot = BLOCKS_PER_INDIR_BLOCK + 1;
|
1999-10-16 19:49:28 +00:00
|
|
|
}
|
|
|
|
indirect->nextSlot--;
|
2000-04-12 17:17:23 +00:00
|
|
|
return indirect->ptrs[indirect->nextSlot - 1];
|
1999-10-16 19:49:28 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Create a set of logical tapes in a temporary underlying file.
|
|
|
|
*
|
|
|
|
* Each tape is initialized in write state.
|
|
|
|
*/
|
|
|
|
LogicalTapeSet *
|
|
|
|
LogicalTapeSetCreate(int ntapes)
|
|
|
|
{
|
|
|
|
LogicalTapeSet *lts;
|
2000-04-12 17:17:23 +00:00
|
|
|
LogicalTape *lt;
|
|
|
|
int i;
|
1999-10-16 19:49:28 +00:00
|
|
|
|
|
|
|
/*
|
2015-02-21 16:12:14 -05:00
|
|
|
* Create top-level struct including per-tape LogicalTape structs.
|
1999-10-16 19:49:28 +00:00
|
|
|
*/
|
|
|
|
Assert(ntapes > 0);
|
2015-02-21 16:12:14 -05:00
|
|
|
lts = (LogicalTapeSet *) palloc(offsetof(LogicalTapeSet, tapes) +
|
|
|
|
ntapes * sizeof(LogicalTape));
|
2007-06-07 19:19:57 +00:00
|
|
|
lts->pfile = BufFileCreateTemp(false);
|
1999-10-16 19:49:28 +00:00
|
|
|
lts->nFileBlocks = 0L;
|
2006-03-07 19:06:50 +00:00
|
|
|
lts->forgetFreeSpace = false;
|
2006-03-07 23:46:24 +00:00
|
|
|
lts->blocksSorted = true; /* a zero-length array is sorted ... */
|
1999-10-16 19:49:28 +00:00
|
|
|
lts->freeBlocksLen = 32; /* reasonable initial guess */
|
|
|
|
lts->freeBlocks = (long *) palloc(lts->freeBlocksLen * sizeof(long));
|
|
|
|
lts->nFreeBlocks = 0;
|
|
|
|
lts->nTapes = ntapes;
|
2000-04-12 17:17:23 +00:00
|
|
|
|
1999-10-16 19:49:28 +00:00
|
|
|
/*
|
2006-02-19 05:58:36 +00:00
|
|
|
* Initialize per-tape structs. Note we allocate the I/O buffer and
|
|
|
|
* first-level indirect block for a tape only when it is first actually
|
2014-05-06 12:12:18 -04:00
|
|
|
* written to. This avoids wasting memory space when tuplesort.c
|
2006-02-19 05:58:36 +00:00
|
|
|
* overestimates the number of tapes needed.
|
1999-10-16 19:49:28 +00:00
|
|
|
*/
|
|
|
|
for (i = 0; i < ntapes; i++)
|
|
|
|
{
|
2006-02-19 05:58:36 +00:00
|
|
|
lt = <s->tapes[i];
|
|
|
|
lt->indirect = NULL;
|
1999-10-16 19:49:28 +00:00
|
|
|
lt->writing = true;
|
|
|
|
lt->frozen = false;
|
|
|
|
lt->dirty = false;
|
|
|
|
lt->numFullBlocks = 0L;
|
|
|
|
lt->lastBlockBytes = 0;
|
2006-02-19 05:58:36 +00:00
|
|
|
lt->buffer = NULL;
|
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>
2016-10-03 13:37:49 +03:00
|
|
|
lt->buffer_size = 0;
|
|
|
|
lt->read_buffer_size = BLCKSZ;
|
1999-10-16 19:49:28 +00:00
|
|
|
lt->curBlockNumber = 0L;
|
|
|
|
lt->pos = 0;
|
|
|
|
lt->nbytes = 0;
|
|
|
|
}
|
|
|
|
return lts;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Close a logical tape set and release all resources.
|
|
|
|
*/
|
2000-04-12 17:17:23 +00:00
|
|
|
void
|
|
|
|
LogicalTapeSetClose(LogicalTapeSet *lts)
|
1999-10-16 19:49:28 +00:00
|
|
|
{
|
2000-04-12 17:17:23 +00:00
|
|
|
LogicalTape *lt;
|
|
|
|
IndirectBlock *ib,
|
|
|
|
*nextib;
|
|
|
|
int i;
|
1999-10-16 19:49:28 +00:00
|
|
|
|
|
|
|
BufFileClose(lts->pfile);
|
|
|
|
for (i = 0; i < lts->nTapes; i++)
|
|
|
|
{
|
2006-02-19 05:58:36 +00:00
|
|
|
lt = <s->tapes[i];
|
1999-10-16 19:49:28 +00:00
|
|
|
for (ib = lt->indirect; ib != NULL; ib = nextib)
|
|
|
|
{
|
|
|
|
nextib = ib->nextup;
|
|
|
|
pfree(ib);
|
|
|
|
}
|
2006-02-19 05:58:36 +00:00
|
|
|
if (lt->buffer)
|
|
|
|
pfree(lt->buffer);
|
1999-10-16 19:49:28 +00:00
|
|
|
}
|
|
|
|
pfree(lts->freeBlocks);
|
|
|
|
pfree(lts);
|
|
|
|
}
|
|
|
|
|
2006-03-07 19:06:50 +00:00
|
|
|
/*
|
|
|
|
* Mark a logical tape set as not needing management of free space anymore.
|
|
|
|
*
|
|
|
|
* This should be called if the caller does not intend to write any more data
|
2014-05-06 12:12:18 -04:00
|
|
|
* into the tape set, but is reading from un-frozen tapes. Since no more
|
2006-03-07 19:06:50 +00:00
|
|
|
* writes are planned, remembering free blocks is no longer useful. Setting
|
|
|
|
* this flag lets us avoid wasting time and space in ltsReleaseBlock(), which
|
|
|
|
* is not designed to handle large numbers of free blocks.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
LogicalTapeSetForgetFreeSpace(LogicalTapeSet *lts)
|
|
|
|
{
|
|
|
|
lts->forgetFreeSpace = true;
|
|
|
|
}
|
|
|
|
|
1999-10-16 19:49:28 +00:00
|
|
|
/*
|
|
|
|
* Dump the dirty buffer of a logical tape.
|
|
|
|
*/
|
|
|
|
static void
|
|
|
|
ltsDumpBuffer(LogicalTapeSet *lts, LogicalTape *lt)
|
|
|
|
{
|
2000-04-12 17:17:23 +00:00
|
|
|
long datablock = ltsGetFreeBlock(lts);
|
1999-10-16 19:49:28 +00:00
|
|
|
|
|
|
|
Assert(lt->dirty);
|
|
|
|
ltsWriteBlock(lts, datablock, (void *) lt->buffer);
|
|
|
|
ltsRecordBlockNum(lts, lt->indirect, datablock);
|
|
|
|
lt->dirty = false;
|
|
|
|
/* Caller must do other state update as needed */
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Write to a logical tape.
|
|
|
|
*
|
2003-07-25 20:18:01 +00:00
|
|
|
* There are no error returns; we ereport() on failure.
|
1999-10-16 19:49:28 +00:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
LogicalTapeWrite(LogicalTapeSet *lts, int tapenum,
|
|
|
|
void *ptr, size_t size)
|
|
|
|
{
|
2000-04-12 17:17:23 +00:00
|
|
|
LogicalTape *lt;
|
|
|
|
size_t nthistime;
|
1999-10-16 19:49:28 +00:00
|
|
|
|
|
|
|
Assert(tapenum >= 0 && tapenum < lts->nTapes);
|
2006-02-19 05:58:36 +00:00
|
|
|
lt = <s->tapes[tapenum];
|
1999-10-16 19:49:28 +00:00
|
|
|
Assert(lt->writing);
|
|
|
|
|
2006-02-19 05:58:36 +00:00
|
|
|
/* Allocate data buffer and first indirect block on first write */
|
|
|
|
if (lt->buffer == NULL)
|
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>
2016-10-03 13:37:49 +03:00
|
|
|
{
|
2006-02-19 05:58:36 +00:00
|
|
|
lt->buffer = (char *) palloc(BLCKSZ);
|
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>
2016-10-03 13:37:49 +03:00
|
|
|
lt->buffer_size = BLCKSZ;
|
|
|
|
}
|
2006-02-19 05:58:36 +00:00
|
|
|
if (lt->indirect == NULL)
|
|
|
|
{
|
|
|
|
lt->indirect = (IndirectBlock *) palloc(sizeof(IndirectBlock));
|
|
|
|
lt->indirect->nextSlot = 0;
|
|
|
|
lt->indirect->nextup = NULL;
|
|
|
|
}
|
|
|
|
|
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>
2016-10-03 13:37:49 +03:00
|
|
|
Assert(lt->buffer_size == BLCKSZ);
|
1999-10-16 19:49:28 +00:00
|
|
|
while (size > 0)
|
|
|
|
{
|
|
|
|
if (lt->pos >= BLCKSZ)
|
|
|
|
{
|
|
|
|
/* Buffer full, dump it out */
|
|
|
|
if (lt->dirty)
|
|
|
|
ltsDumpBuffer(lts, lt);
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/* Hmm, went directly from reading to writing? */
|
2003-07-25 20:18:01 +00:00
|
|
|
elog(ERROR, "invalid logtape state: should be dirty");
|
1999-10-16 19:49:28 +00:00
|
|
|
}
|
|
|
|
lt->numFullBlocks++;
|
|
|
|
lt->curBlockNumber++;
|
|
|
|
lt->pos = 0;
|
|
|
|
lt->nbytes = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
nthistime = BLCKSZ - lt->pos;
|
|
|
|
if (nthistime > size)
|
|
|
|
nthistime = size;
|
|
|
|
Assert(nthistime > 0);
|
|
|
|
|
|
|
|
memcpy(lt->buffer + lt->pos, ptr, nthistime);
|
|
|
|
|
|
|
|
lt->dirty = true;
|
|
|
|
lt->pos += nthistime;
|
|
|
|
if (lt->nbytes < lt->pos)
|
|
|
|
lt->nbytes = lt->pos;
|
|
|
|
ptr = (void *) ((char *) ptr + nthistime);
|
|
|
|
size -= nthistime;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Rewind logical tape and switch from writing to reading or vice versa.
|
|
|
|
*
|
|
|
|
* Unless the tape has been "frozen" in read state, forWrite must be the
|
|
|
|
* opposite of the previous tape state.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
LogicalTapeRewind(LogicalTapeSet *lts, int tapenum, bool forWrite)
|
|
|
|
{
|
2000-04-12 17:17:23 +00:00
|
|
|
LogicalTape *lt;
|
|
|
|
long datablocknum;
|
1999-10-16 19:49:28 +00:00
|
|
|
|
|
|
|
Assert(tapenum >= 0 && tapenum < lts->nTapes);
|
2006-02-19 05:58:36 +00:00
|
|
|
lt = <s->tapes[tapenum];
|
1999-10-16 19:49:28 +00:00
|
|
|
|
2000-04-12 17:17:23 +00:00
|
|
|
if (!forWrite)
|
1999-10-16 19:49:28 +00:00
|
|
|
{
|
|
|
|
if (lt->writing)
|
|
|
|
{
|
|
|
|
/*
|
2005-10-15 02:49:52 +00:00
|
|
|
* Completion of a write phase. Flush last partial data block,
|
|
|
|
* flush any partial indirect blocks, rewind for normal
|
2000-04-12 17:17:23 +00:00
|
|
|
* (destructive) read.
|
1999-10-16 19:49:28 +00:00
|
|
|
*/
|
|
|
|
if (lt->dirty)
|
|
|
|
ltsDumpBuffer(lts, lt);
|
|
|
|
lt->lastBlockBytes = lt->nbytes;
|
|
|
|
lt->writing = false;
|
|
|
|
datablocknum = ltsRewindIndirectBlock(lts, lt->indirect, false);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
2005-10-15 02:49:52 +00:00
|
|
|
* This is only OK if tape is frozen; we rewind for (another) read
|
|
|
|
* pass.
|
1999-10-16 19:49:28 +00:00
|
|
|
*/
|
|
|
|
Assert(lt->frozen);
|
|
|
|
datablocknum = ltsRewindFrozenIndirectBlock(lts, lt->indirect);
|
|
|
|
}
|
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>
2016-10-03 13:37:49 +03:00
|
|
|
|
2016-10-06 09:46:40 +03:00
|
|
|
/* Allocate a read buffer (unless the tape is empty) */
|
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>
2016-10-03 13:37:49 +03:00
|
|
|
if (lt->buffer)
|
|
|
|
pfree(lt->buffer);
|
2016-10-06 09:46:40 +03:00
|
|
|
lt->buffer = NULL;
|
|
|
|
lt->buffer_size = 0;
|
|
|
|
if (datablocknum != -1L)
|
|
|
|
{
|
|
|
|
lt->buffer = palloc(lt->read_buffer_size);
|
|
|
|
lt->buffer_size = lt->read_buffer_size;
|
|
|
|
}
|
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>
2016-10-03 13:37:49 +03:00
|
|
|
|
1999-10-16 19:49:28 +00:00
|
|
|
/* Read the first block, or reset if tape is empty */
|
|
|
|
lt->curBlockNumber = 0L;
|
|
|
|
lt->pos = 0;
|
|
|
|
lt->nbytes = 0;
|
|
|
|
if (datablocknum != -1L)
|
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>
2016-10-03 13:37:49 +03:00
|
|
|
ltsReadFillBuffer(lts, lt, datablocknum);
|
1999-10-16 19:49:28 +00:00
|
|
|
}
|
|
|
|
else
|
|
|
|
{
|
|
|
|
/*
|
2014-05-06 12:12:18 -04:00
|
|
|
* Completion of a read phase. Rewind and prepare for write.
|
1999-10-16 19:49:28 +00:00
|
|
|
*
|
2000-04-12 17:17:23 +00:00
|
|
|
* NOTE: we assume the caller has read the tape to the end; otherwise
|
|
|
|
* untouched data and indirect blocks will not have been freed. We
|
2005-10-15 02:49:52 +00:00
|
|
|
* could add more code to free any unread blocks, but in current usage
|
|
|
|
* of this module it'd be useless code.
|
1999-10-16 19:49:28 +00:00
|
|
|
*/
|
2000-04-12 17:17:23 +00:00
|
|
|
IndirectBlock *ib,
|
|
|
|
*nextib;
|
1999-10-16 19:49:28 +00:00
|
|
|
|
2000-04-12 17:17:23 +00:00
|
|
|
Assert(!lt->writing && !lt->frozen);
|
1999-10-16 19:49:28 +00:00
|
|
|
/* Must truncate the indirect-block hierarchy down to one level. */
|
2006-02-19 05:58:36 +00:00
|
|
|
if (lt->indirect)
|
1999-10-16 19:49:28 +00:00
|
|
|
{
|
2006-02-19 05:58:36 +00:00
|
|
|
for (ib = lt->indirect->nextup; ib != NULL; ib = nextib)
|
|
|
|
{
|
|
|
|
nextib = ib->nextup;
|
|
|
|
pfree(ib);
|
|
|
|
}
|
|
|
|
lt->indirect->nextSlot = 0;
|
|
|
|
lt->indirect->nextup = NULL;
|
1999-10-16 19:49:28 +00:00
|
|
|
}
|
|
|
|
lt->writing = true;
|
|
|
|
lt->dirty = false;
|
|
|
|
lt->numFullBlocks = 0L;
|
|
|
|
lt->lastBlockBytes = 0;
|
|
|
|
lt->curBlockNumber = 0L;
|
|
|
|
lt->pos = 0;
|
|
|
|
lt->nbytes = 0;
|
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>
2016-10-03 13:37:49 +03:00
|
|
|
|
|
|
|
if (lt->buffer)
|
|
|
|
{
|
|
|
|
pfree(lt->buffer);
|
|
|
|
lt->buffer = NULL;
|
|
|
|
lt->buffer_size = 0;
|
|
|
|
}
|
1999-10-16 19:49:28 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Read from a logical tape.
|
|
|
|
*
|
|
|
|
* Early EOF is indicated by return value less than #bytes requested.
|
|
|
|
*/
|
|
|
|
size_t
|
|
|
|
LogicalTapeRead(LogicalTapeSet *lts, int tapenum,
|
|
|
|
void *ptr, size_t size)
|
|
|
|
{
|
2000-04-12 17:17:23 +00:00
|
|
|
LogicalTape *lt;
|
|
|
|
size_t nread = 0;
|
|
|
|
size_t nthistime;
|
1999-10-16 19:49:28 +00:00
|
|
|
|
|
|
|
Assert(tapenum >= 0 && tapenum < lts->nTapes);
|
2006-02-19 05:58:36 +00:00
|
|
|
lt = <s->tapes[tapenum];
|
2000-04-12 17:17:23 +00:00
|
|
|
Assert(!lt->writing);
|
1999-10-16 19:49:28 +00:00
|
|
|
|
|
|
|
while (size > 0)
|
|
|
|
{
|
|
|
|
if (lt->pos >= lt->nbytes)
|
|
|
|
{
|
|
|
|
/* Try to load more data into buffer. */
|
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>
2016-10-03 13:37:49 +03:00
|
|
|
if (!ltsReadFillBuffer(lts, lt, -1))
|
1999-10-16 19:49:28 +00:00
|
|
|
break; /* EOF */
|
|
|
|
}
|
|
|
|
|
|
|
|
nthistime = lt->nbytes - lt->pos;
|
|
|
|
if (nthistime > size)
|
|
|
|
nthistime = size;
|
|
|
|
Assert(nthistime > 0);
|
|
|
|
|
|
|
|
memcpy(ptr, lt->buffer + lt->pos, nthistime);
|
|
|
|
|
|
|
|
lt->pos += nthistime;
|
|
|
|
ptr = (void *) ((char *) ptr + nthistime);
|
|
|
|
size -= nthistime;
|
|
|
|
nread += nthistime;
|
|
|
|
}
|
|
|
|
|
|
|
|
return nread;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* "Freeze" the contents of a tape so that it can be read multiple times
|
|
|
|
* and/or read backwards. Once a tape is frozen, its contents will not
|
|
|
|
* be released until the LogicalTapeSet is destroyed. This is expected
|
|
|
|
* to be used only for the final output pass of a merge.
|
|
|
|
*
|
|
|
|
* This *must* be called just at the end of a write pass, before the
|
|
|
|
* tape is rewound (after rewind is too late!). It performs a rewind
|
2014-05-06 12:12:18 -04:00
|
|
|
* and switch to read mode "for free". An immediately following rewind-
|
1999-10-16 19:49:28 +00:00
|
|
|
* for-read call is OK but not necessary.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
LogicalTapeFreeze(LogicalTapeSet *lts, int tapenum)
|
|
|
|
{
|
2000-04-12 17:17:23 +00:00
|
|
|
LogicalTape *lt;
|
|
|
|
long datablocknum;
|
1999-10-16 19:49:28 +00:00
|
|
|
|
|
|
|
Assert(tapenum >= 0 && tapenum < lts->nTapes);
|
2006-02-19 05:58:36 +00:00
|
|
|
lt = <s->tapes[tapenum];
|
1999-10-16 19:49:28 +00:00
|
|
|
Assert(lt->writing);
|
|
|
|
|
|
|
|
/*
|
2005-10-15 02:49:52 +00:00
|
|
|
* Completion of a write phase. Flush last partial data block, flush any
|
|
|
|
* partial indirect blocks, rewind for nondestructive read.
|
1999-10-16 19:49:28 +00:00
|
|
|
*/
|
|
|
|
if (lt->dirty)
|
|
|
|
ltsDumpBuffer(lts, lt);
|
|
|
|
lt->lastBlockBytes = lt->nbytes;
|
|
|
|
lt->writing = false;
|
|
|
|
lt->frozen = true;
|
|
|
|
datablocknum = ltsRewindIndirectBlock(lts, lt->indirect, true);
|
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>
2016-10-03 13:37:49 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The seek and backspace functions assume a single block read buffer.
|
|
|
|
* That's OK with current usage. A larger buffer is helpful to make the
|
|
|
|
* read pattern of the backing file look more sequential to the OS, when
|
|
|
|
* we're reading from multiple tapes. But at the end of a sort, when a
|
|
|
|
* tape is frozen, we only read from a single tape anyway.
|
|
|
|
*/
|
|
|
|
if (!lt->buffer || lt->buffer_size != BLCKSZ)
|
|
|
|
{
|
|
|
|
if (lt->buffer)
|
|
|
|
pfree(lt->buffer);
|
|
|
|
lt->buffer = palloc(BLCKSZ);
|
|
|
|
lt->buffer_size = BLCKSZ;
|
|
|
|
}
|
|
|
|
|
1999-10-16 19:49:28 +00:00
|
|
|
/* Read the first block, or reset if tape is empty */
|
|
|
|
lt->curBlockNumber = 0L;
|
|
|
|
lt->pos = 0;
|
|
|
|
lt->nbytes = 0;
|
|
|
|
if (datablocknum != -1L)
|
|
|
|
{
|
|
|
|
ltsReadBlock(lts, datablocknum, (void *) lt->buffer);
|
|
|
|
lt->nbytes = (lt->curBlockNumber < lt->numFullBlocks) ?
|
|
|
|
BLCKSZ : lt->lastBlockBytes;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
2014-05-06 12:12:18 -04:00
|
|
|
* Backspace the tape a given number of bytes. (We also support a more
|
1999-10-16 19:49:28 +00:00
|
|
|
* general seek interface, see below.)
|
|
|
|
*
|
|
|
|
* *Only* a frozen-for-read tape can be backed up; we don't support
|
|
|
|
* random access during write, and an unfrozen read tape may have
|
|
|
|
* already discarded the desired data!
|
|
|
|
*
|
|
|
|
* Return value is TRUE if seek successful, FALSE if there isn't that much
|
|
|
|
* data before the current point (in which case there's no state change).
|
|
|
|
*/
|
|
|
|
bool
|
|
|
|
LogicalTapeBackspace(LogicalTapeSet *lts, int tapenum, size_t size)
|
|
|
|
{
|
2000-04-12 17:17:23 +00:00
|
|
|
LogicalTape *lt;
|
|
|
|
long nblocks;
|
|
|
|
int newpos;
|
1999-10-16 19:49:28 +00:00
|
|
|
|
|
|
|
Assert(tapenum >= 0 && tapenum < lts->nTapes);
|
2006-02-19 05:58:36 +00:00
|
|
|
lt = <s->tapes[tapenum];
|
1999-10-16 19:49:28 +00:00
|
|
|
Assert(lt->frozen);
|
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>
2016-10-03 13:37:49 +03:00
|
|
|
Assert(lt->buffer_size == BLCKSZ);
|
1999-10-16 19:49:28 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Easy case for seek within current block.
|
|
|
|
*/
|
|
|
|
if (size <= (size_t) lt->pos)
|
|
|
|
{
|
|
|
|
lt->pos -= (int) size;
|
|
|
|
return true;
|
|
|
|
}
|
2000-04-12 17:17:23 +00:00
|
|
|
|
1999-10-16 19:49:28 +00:00
|
|
|
/*
|
|
|
|
* Not-so-easy case. Figure out whether it's possible at all.
|
|
|
|
*/
|
|
|
|
size -= (size_t) lt->pos; /* part within this block */
|
|
|
|
nblocks = size / BLCKSZ;
|
|
|
|
size = size % BLCKSZ;
|
|
|
|
if (size)
|
|
|
|
{
|
|
|
|
nblocks++;
|
|
|
|
newpos = (int) (BLCKSZ - size);
|
|
|
|
}
|
|
|
|
else
|
|
|
|
newpos = 0;
|
|
|
|
if (nblocks > lt->curBlockNumber)
|
|
|
|
return false; /* a seek too far... */
|
2000-04-12 17:17:23 +00:00
|
|
|
|
1999-10-16 19:49:28 +00:00
|
|
|
/*
|
2005-10-15 02:49:52 +00:00
|
|
|
* OK, we need to back up nblocks blocks. This implementation would be
|
|
|
|
* pretty inefficient for long seeks, but we really aren't expecting that
|
|
|
|
* (a seek over one tuple is typical).
|
1999-10-16 19:49:28 +00:00
|
|
|
*/
|
|
|
|
while (nblocks-- > 0)
|
|
|
|
{
|
2000-04-12 17:17:23 +00:00
|
|
|
long datablocknum = ltsRecallPrevBlockNum(lts, lt->indirect);
|
1999-10-16 19:49:28 +00:00
|
|
|
|
|
|
|
if (datablocknum == -1L)
|
2003-07-25 20:18:01 +00:00
|
|
|
elog(ERROR, "unexpected end of tape");
|
1999-10-16 19:49:28 +00:00
|
|
|
lt->curBlockNumber--;
|
|
|
|
if (nblocks == 0)
|
|
|
|
{
|
|
|
|
ltsReadBlock(lts, datablocknum, (void *) lt->buffer);
|
|
|
|
lt->nbytes = BLCKSZ;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
lt->pos = newpos;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Seek to an arbitrary position in a logical tape.
|
|
|
|
*
|
|
|
|
* *Only* a frozen-for-read tape can be seeked.
|
|
|
|
*
|
|
|
|
* Return value is TRUE if seek successful, FALSE if there isn't that much
|
|
|
|
* data in the tape (in which case there's no state change).
|
|
|
|
*/
|
|
|
|
bool
|
|
|
|
LogicalTapeSeek(LogicalTapeSet *lts, int tapenum,
|
|
|
|
long blocknum, int offset)
|
|
|
|
{
|
2000-04-12 17:17:23 +00:00
|
|
|
LogicalTape *lt;
|
1999-10-16 19:49:28 +00:00
|
|
|
|
|
|
|
Assert(tapenum >= 0 && tapenum < lts->nTapes);
|
2006-02-19 05:58:36 +00:00
|
|
|
lt = <s->tapes[tapenum];
|
1999-10-16 19:49:28 +00:00
|
|
|
Assert(lt->frozen);
|
|
|
|
Assert(offset >= 0 && offset <= BLCKSZ);
|
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>
2016-10-03 13:37:49 +03:00
|
|
|
Assert(lt->buffer_size == BLCKSZ);
|
1999-10-16 19:49:28 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Easy case for seek within current block.
|
|
|
|
*/
|
|
|
|
if (blocknum == lt->curBlockNumber && offset <= lt->nbytes)
|
|
|
|
{
|
|
|
|
lt->pos = offset;
|
|
|
|
return true;
|
|
|
|
}
|
2000-04-12 17:17:23 +00:00
|
|
|
|
1999-10-16 19:49:28 +00:00
|
|
|
/*
|
|
|
|
* Not-so-easy case. Figure out whether it's possible at all.
|
|
|
|
*/
|
|
|
|
if (blocknum < 0 || blocknum > lt->numFullBlocks ||
|
|
|
|
(blocknum == lt->numFullBlocks && offset > lt->lastBlockBytes))
|
|
|
|
return false;
|
2000-04-12 17:17:23 +00:00
|
|
|
|
1999-10-16 19:49:28 +00:00
|
|
|
/*
|
2014-05-06 12:12:18 -04:00
|
|
|
* OK, advance or back up to the target block. This implementation would
|
2005-10-15 02:49:52 +00:00
|
|
|
* be pretty inefficient for long seeks, but we really aren't expecting
|
|
|
|
* that (a seek over one tuple is typical).
|
1999-10-16 19:49:28 +00:00
|
|
|
*/
|
|
|
|
while (lt->curBlockNumber > blocknum)
|
|
|
|
{
|
2000-04-12 17:17:23 +00:00
|
|
|
long datablocknum = ltsRecallPrevBlockNum(lts, lt->indirect);
|
1999-10-16 19:49:28 +00:00
|
|
|
|
|
|
|
if (datablocknum == -1L)
|
2003-07-25 20:18:01 +00:00
|
|
|
elog(ERROR, "unexpected end of tape");
|
1999-10-16 19:49:28 +00:00
|
|
|
if (--lt->curBlockNumber == blocknum)
|
|
|
|
ltsReadBlock(lts, datablocknum, (void *) lt->buffer);
|
|
|
|
}
|
|
|
|
while (lt->curBlockNumber < blocknum)
|
|
|
|
{
|
2000-04-12 17:17:23 +00:00
|
|
|
long datablocknum = ltsRecallNextBlockNum(lts, lt->indirect,
|
|
|
|
lt->frozen);
|
1999-10-16 19:49:28 +00:00
|
|
|
|
|
|
|
if (datablocknum == -1L)
|
2003-07-25 20:18:01 +00:00
|
|
|
elog(ERROR, "unexpected end of tape");
|
1999-10-16 19:49:28 +00:00
|
|
|
if (++lt->curBlockNumber == blocknum)
|
|
|
|
ltsReadBlock(lts, datablocknum, (void *) lt->buffer);
|
|
|
|
}
|
|
|
|
lt->nbytes = (lt->curBlockNumber < lt->numFullBlocks) ?
|
|
|
|
BLCKSZ : lt->lastBlockBytes;
|
|
|
|
lt->pos = offset;
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Obtain current position in a form suitable for a later LogicalTapeSeek.
|
|
|
|
*
|
|
|
|
* NOTE: it'd be OK to do this during write phase with intention of using
|
2014-05-06 12:12:18 -04:00
|
|
|
* the position for a seek after freezing. Not clear if anyone needs that.
|
1999-10-16 19:49:28 +00:00
|
|
|
*/
|
|
|
|
void
|
|
|
|
LogicalTapeTell(LogicalTapeSet *lts, int tapenum,
|
|
|
|
long *blocknum, int *offset)
|
|
|
|
{
|
2000-04-12 17:17:23 +00:00
|
|
|
LogicalTape *lt;
|
1999-10-16 19:49:28 +00:00
|
|
|
|
|
|
|
Assert(tapenum >= 0 && tapenum < lts->nTapes);
|
2006-02-19 05:58:36 +00:00
|
|
|
lt = <s->tapes[tapenum];
|
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>
2016-10-03 13:37:49 +03:00
|
|
|
|
|
|
|
/* With a larger buffer, 'pos' wouldn't be the same as offset within page */
|
|
|
|
Assert(lt->buffer_size == BLCKSZ);
|
|
|
|
|
1999-10-16 19:49:28 +00:00
|
|
|
*blocknum = lt->curBlockNumber;
|
|
|
|
*offset = lt->pos;
|
|
|
|
}
|
2005-10-18 22:59:37 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Obtain total disk space currently used by a LogicalTapeSet, in blocks.
|
|
|
|
*/
|
|
|
|
long
|
|
|
|
LogicalTapeSetBlocks(LogicalTapeSet *lts)
|
|
|
|
{
|
|
|
|
return lts->nFileBlocks;
|
|
|
|
}
|
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>
2016-10-03 13:37:49 +03:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Set buffer size to use, when reading from given tape.
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
LogicalTapeAssignReadBufferSize(LogicalTapeSet *lts, int tapenum, size_t avail_mem)
|
|
|
|
{
|
|
|
|
LogicalTape *lt;
|
|
|
|
|
|
|
|
Assert(tapenum >= 0 && tapenum < lts->nTapes);
|
|
|
|
lt = <s->tapes[tapenum];
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The buffer size must be a multiple of BLCKSZ in size, so round the
|
|
|
|
* given value down to nearest BLCKSZ. Make sure we have at least one
|
|
|
|
* page. Also, don't go above MaxAllocSize, to avoid erroring out. A
|
|
|
|
* multi-gigabyte buffer is unlikely to be helpful, anyway.
|
|
|
|
*/
|
|
|
|
if (avail_mem < BLCKSZ)
|
|
|
|
avail_mem = BLCKSZ;
|
|
|
|
if (avail_mem > MaxAllocSize)
|
|
|
|
avail_mem = MaxAllocSize;
|
|
|
|
avail_mem -= avail_mem % BLCKSZ;
|
|
|
|
lt->read_buffer_size = avail_mem;
|
|
|
|
}
|