Re: Using quicksort for every external sort run
От | Jeff Janes |
---|---|
Тема | Re: Using quicksort for every external sort run |
Дата | |
Msg-id | CAMkU=1zp=vx1E0iawmFq1Fby6Gb+FDqsRMppa=fHVLYeUTdFWg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Using quicksort for every external sort run (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: Using quicksort for every external sort run
|
Список | pgsql-hackers |
On Sun, Dec 6, 2015 at 4:25 PM, Peter Geoghegan <pg@heroku.com> wrote: > Maybe we should consider trying to get patch 0002 (the memory > pool/merge patch) committed first, something Greg Stark suggested > privately. That might actually be an easier way of integrating this > work, since it changes nothing about the algorithm we use for merging > (it only improves memory locality), and so is really an independent > piece of work (albeit one that makes a huge overall difference due to > the other patches increasing the time spent merging in absolute terms, > and especially as a proportion of the total). 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. 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? Cheers, Jeff
В списке pgsql-hackers по дате отправления: