Re: Compression and on-disk sorting - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: Compression and on-disk sorting
Date
Msg-id 20060518183210.GD4359@svana.org
Whole thread Raw
In response to Re: Compression and on-disk sorting  ("Jim C. Nasby" <jnasby@pervasive.com>)
Responses Re: Compression and on-disk sorting  ("Jim C. Nasby" <jnasby@pervasive.com>)
List pgsql-hackers
On Thu, May 18, 2006 at 11:22:46AM -0500, Jim C. Nasby wrote:
> 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.

Logtape works with BLCKSZ blocks. Whether it's advisable or not, I
don't know. One thing I'm noticing with this compression-in-logtape is
that the memory cost per tape increases considerably. Currently we rely
heavily on the OS to cache for us.

Lets say we buffer 256KB per tape, and we assume a large sort with many
tapes, you're going to blow all your work_mem on buffers. If using
compression uses more memory so that you can't have as many tapes and
thus need multiple passes, well, we need to test if this is still a
win.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

pgsql-hackers by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: [OT] MySQL is bad, but THIS bad?
Next
From: Stephen Frost
Date:
Subject: Re: [OT] MySQL is bad, but THIS bad?