Re: [HACKERS] Tuplesort merge pre-reading

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