| From: | "Zeugswetter Andreas DCP SD" <ZeugswetterA(at)spardat(dot)at> |
|---|---|
| To: | "Greg Stark" <gsstark(at)mit(dot)edu>, "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
| Cc: | "Martijn van Oosterhout" <kleptog(at)svana(dot)org>, "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "Rod Taylor" <pg(at)rbt(dot)ca>, "Bort, Paul" <pbort(at)tmwsystems(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Compression and on-disk sorting |
| Date: | 2006-05-18 08:57:16 |
| Message-ID: | E1539E0ED7043848906A8FF995BDA57901054657@m0143.s-mxs.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 1) Use n sort areas for n tapes making everything purely sequential
access.
Some time ago testing I did has shown, that iff the IO block size is
large enough
(256k) it does not really matter that much if the blocks are at random
locations.
I think that is still true for current model disks.
So unless we parallelize, it is imho sufficient to see to it that we
write
(and read) large enough blocks with single calls. This also has no
problem in
highly concurrent scenarios, where you do not have enough spindles.
Andreas
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2006-05-18 09:01:17 | Re: does wal archiving block the current client connection? |
| Previous Message | Martijn van Oosterhout | 2006-05-18 08:31:03 | Re: [PATCH] Compression and on-disk sorting |