Re: Merge algorithms for large numbers of "tapes"

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Merge algorithms for large numbers of "tapes"
Дата
Msg-id 28664.1141948782@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Merge algorithms for large numbers of "tapes"  (Stephen Frost <sfrost@snowman.net>)
Ответы Re: Merge algorithms for large numbers of "tapes"  ("Luke Lonergan" <llonergan@greenplum.com>)
Список pgsql-hackers
Stephen Frost <sfrost@snowman.net> writes:
> So, if we get a huge performance increase, what's wrong with:
> if [ sqrt(est(total)) <=3D work_mem ]; then
>   two-pass-sort();
> else
>   tape-sort();
> fi
> ?

Possibly nothing.  However, from an algorithmic point of view the
CVS-tip code *is* two-pass-sort, given adequate work_mem and no
requirement for random access.  Further, the available profile data
doesn't show any indication that the logtape.c code is eating 3/4ths
of the time (at least not after we fixed the ltsReleaseBlock problem).
So I basically do not believe Luke's assertion that removing logtape.c
is going to produce a 4X speedup.  Maybe it's time to produce some code
that we can all test.
        regards, tom lane


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

Предыдущее
От: "Dann Corbit"
Дата:
Сообщение: Re: Merge algorithms for large numbers of "tapes"
Следующее
От: "Luke Lonergan"
Дата:
Сообщение: Re: Merge algorithms for large numbers of "tapes"