Re: Using quicksort for every external sort run
От | Peter Geoghegan |
---|---|
Тема | Re: Using quicksort for every external sort run |
Дата | |
Msg-id | CAM3SWZSKGd+gYAbP=g4x-n4SL0PMPQ-VgYwAzMa_dXPgiSsjpA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Using quicksort for every external sort run (Jeff Janes <jeff.janes@gmail.com>) |
Ответы |
Re: Using quicksort for every external sort run
Re: Using quicksort for every external sort run |
Список | pgsql-hackers |
On Sat, Dec 12, 2015 at 12:10 AM, Jeff Janes <jeff.janes@gmail.com> wrote: > I have a question about the terminology used in this patch. What is a > tuple proper? What is it in contradistinction to? I would think that > a tuple which is located in its own palloc'ed space is the "proper" > one, leaving a tuple allocated in the bulk memory pool to be > called...something else. I don't know what the > non-judgmental-sounding antonym of postpositive "proper" is. "Tuple proper" is a term that appears 5 times in tuplesort.c today. As it says at the top of that file: /** The objects we actually sort are SortTuple structs. These contain* a pointer to the tuple proper (might be a MinimalTupleor IndexTuple),* which is a separate palloc chunk --- we assume it is just one chunk and* can be freed by a simplepfree(). SortTuples also contain the tuple's* first key column in Datum/nullflag format, and an index integer. > Also, if I am reading this correctly, when we refill a pool from a > logical tape we still transform each tuple as it is read from the disk > format to the memory format. This inflates the size quite a bit, at > least for single-datum tuples. If we instead just read the disk > format directly into the pool, and converted them into the in-memory > format when each tuple came due for the merge heap, would that destroy > the locality of reference you are seeking to gain? Are you talking about alignment? -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: