From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
---|---|
To: | Zeugswetter Andreas DCP SD <ZeugswetterA(at)spardat(dot)at> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, 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 16:22:46 |
Message-ID: | 20060518162245.GJ64371@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, May 18, 2006 at 10:57:16AM +0200, Zeugswetter Andreas DCP SD wrote:
>
> > 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.
AFAIK logtape currently reads in much less than 256k blocks. Of course
if you get lucky you'll read from one tape for some time before
switching to another, which should have a sort-of similar effect if the
drives aren't very busy with other things.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2006-05-18 16:24:21 | Re: [OT] MySQL is bad, but THIS bad? |
Previous Message | Jim C. Nasby | 2006-05-18 16:18:51 | Re: Compression and on-disk sorting |