Re: Compression and on-disk sorting

From: "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com>
To: Greg Stark <gsstark(at)mit(dot)edu>
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-17 14:56:07
Message-ID: 20060517145607.GJ26212@pervasive.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

On Tue, May 16, 2006 at 06:48:25PM -0400, Greg Stark wrote:
> Martijn van Oosterhout <kleptog(at)svana(dot)org> writes:
>
> > > It might be easier to switch to giving each tape it's own file...
> >
> > I don't think it would make much difference. OTOH, if this turns out to
> > be a win, the tuplestore could have the same optimisation.
>
> Would giving each tape its own file make it easier to allow multiple temporary
> sort areas and allow optimizing to avoid seeking when multiple spindles area
> available?

Only if those spindles weren't all in a single RAID array and if we went
through the trouble of creating all the machinery so you could tell
PostgreSQL where all those spindles were mounted in the filesystem. And
even after all that work, there's not much that says it would perform
better than a simple RAID10.

What *might* make sense would be to provide two locations for pgsql_tmp,
because a lot of operations in there involve reading and writing at the
same time:

Read from heap while writing tapes to pgsql_tmp
read from tapes while writing final version to pgsql_tmp

There's probably some gain to be had by writing the final version to a
tablespace other than the default one (which is where pgsql_tmp would
be, I think). But recent changes in -HEAD mean that the second step is
now only performed in certain cases.
--
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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim C. Nasby 2006-05-17 15:01:33 Re: Compression and on-disk sorting
Previous Message Tom Lane 2006-05-17 14:54:26 Re: What default is - SET behavior

Browse pgsql-patches by date

  From Date Subject
Next Message Jim C. Nasby 2006-05-17 15:01:33 Re: Compression and on-disk sorting
Previous Message Simon Riggs 2006-05-17 14:55:07 Re: SLRU_BLCKSZ