Merge algorithms for large numbers of "tapes"

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Merge algorithms for large numbers of "tapes"
Дата
Msg-id 6293.1141773294@sss.pgh.pa.us
обсуждение исходный текст
Ответы Re: Merge algorithms for large numbers of "tapes"  ("Jonah H. Harris" <jonah.harris@gmail.com>)
Re: Merge algorithms for large numbers of "tapes"  ("Luke Lonergan" <llonergan@greenplum.com>)
Re: Merge algorithms for large numbers of "tapes"  (Simon Riggs <simon@2ndquadrant.com>)
Список pgsql-hackers
BTW, I was just looking over Knuth's discussion of sorting again, and
realized that there is still something more that could be done within
the existing sort framework.  We currently use standard polyphase merge
(his Algorithm 5.4.2D), which IIRC I chose because it was simple and
for relatively small numbers of tapes T it was about as good as anything
else.  Knuth spends a great deal of energy on minimizing tape rewind
time which of course is of no interest to us, and I had supposed that
all of his more-complex algorithms were really only of interest if you
needed to consider rewind time.  However, now that we've changed the
code to prefer large numbers of tapes, it's not at all clear that
Algorithm D is still the right one to use.  In particular I'm looking at
cascade merge, Algorithm 5.4.3C, which appears to use significantly
fewer passes when T is large.  Do you want to try that?
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Coverity Open Source Defect Scan of PostgreSQL
Следующее
От: Mark Kirkwood
Дата:
Сообщение: Re: pg_freespacemap question