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"
|
Список | 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 по дате отправления: