Re: [HACKERS] Tuplesort merge pre-reading - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Tuplesort merge pre-reading
Date
Msg-id CA+TgmoaTpT4oBAZDLx19RxL=f9qOaA7W0zt6==C5C3cmMaFWQQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Tuplesort merge pre-reading  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: [HACKERS] Tuplesort merge pre-reading  (Peter Geoghegan <pg@bowt.ie>)
List 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 by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: [HACKERS] Different table schema in logical replication crashes
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Small patch for pg_basebackup argument parsing