Re: [HACKERS] Tuplesort merge pre-reading

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [HACKERS] Tuplesort merge pre-reading
Дата
Msg-id CA+TgmoaTpT4oBAZDLx19RxL=f9qOaA7W0zt6==C5C3cmMaFWQQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Tuplesort merge pre-reading  (Peter Geoghegan <pg@bowt.ie>)
Ответы Re: [HACKERS] Tuplesort merge pre-reading
Список pgsql-hackers
On Fri, Apr 14, 2017 at 1:19 AM, Peter Geoghegan <pg@bowt.ie> wrote:
> Interestingly enough, I think that Knuth was pretty much spot on with
> his "sweet spot" of 7 tapes, even if you have modern hardware. Commit
> df700e6 (where the sweet spot of merge order 7 was no longer always
> used) was effective because it masked certain overheads that we
> experience when doing multiple passes, overheads that Heikki and I
> mostly removed. This was confirmed by Robert's testing of my merge
> order cap work for commit fc19c18, where he found that using 7 tapes
> was only slightly worse than using many hundreds of tapes. If we could
> somehow be completely effective in making access to logical tapes
> perfectly sequential, then 7 tapes would probably be noticeably
> *faster*, due to CPU caching effects.

I don't think there's any one fixed answer, because increasing the
number of tapes reduces I/O by adding CPU cost, and visca versa.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Petr Jelinek
Дата:
Сообщение: Re: [HACKERS] Different table schema in logical replication crashes
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Small patch for pg_basebackup argument parsing