Re: Tablespaces - Mailing list pgsql-hackers

From scott.marlowe
Subject Re: Tablespaces
Date
Msg-id Pine.LNX.4.33.0402270827300.13785-100000@css120.ihs.com
Whole thread Raw
In response to Re: Tablespaces  (Gavin Sherry <swm@linuxworld.com.au>)
Responses Re: Tablespaces  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, 27 Feb 2004, Gavin Sherry wrote:

> On Thu, 26 Feb 2004, Alex J. Avriette wrote:
> 
> > On Thu, Feb 26, 2004 at 11:22:28PM +1100, Gavin Sherry wrote:
> >
> > > Certainly, table spaces are used in many ways in oracle, db2, etc. You can
> > > mirror data across them, have different buffer sizes for example.
> > > In some implementations, they can be raw disk partitions (no file system).
> > > I don't intend going this far, however.
> >
> > Perhaps now would be a good time to bring up my directio on Solaris question
> > from a year or so back? Is there any interest in the ability to use raw
> > disk?
> 
> I do not intend to undertake raw disk tablespaces for 7.5. I'd be
> interested if anyone could provide some real world benchmarking of file
> system vs. raw disk. Postgres benefits a lot from kernel file system cache
> at the moment. Also, I believe that database designers have traditionally
> made bad file system designers. Raw database partitions often lack the
> tools essential to a scalable environment. For example, the ability to
> resize partitions.

Is possible / reasonable / smart and or dumb to look at implementing the 
tablespaces as riding atop the initlocation handled stuff.  I.e. 
postgresql can only create tablespaces in areas that are created by 
initlocation, thus keeping it in its box, so to speak?



pgsql-hackers by date:

Previous
From: "scott.marlowe"
Date:
Subject: Re: Tablespaces
Next
From: Tom Lane
Date:
Subject: Re: CVS HEAD compile warning