Re: Multiple Storage per Tablespace, or Volumes - Mailing list pgsql-hackers

From Andrew Sullivan
Subject Re: Multiple Storage per Tablespace, or Volumes
Date
Msg-id 20070219195034.GB9448@phlogiston.dyndns.org
Whole thread Raw
In response to Re: Multiple Storage per Tablespace, or Volumes  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Multiple Storage per Tablespace, or Volumes
Re: Multiple Storage per Tablespace, or Volumes
Re: Multiple Storage per Tablespace, or Volumes
Log levels for checkpoint/bgwriter monitoring
List pgsql-hackers
On Mon, Feb 19, 2007 at 10:33:24AM -0500, Tom Lane wrote:
> Martijn van Oosterhout <kleptog@svana.org> writes:
> > Somehow this seems like implementing RAID within postgres,
> 
> RAID and LVM too.  I can't get excited about re-inventing those wheels
> when perfectly good implementations already exist for us to sit on top of.

Ok, warning, this is a "you know what would be sweet" moment.

What would be nice is to be able to detach one of the volumes, and
know the span of the data in there without being able to access the
data.

The problem that a lot of warehouse operators have is something like
this: "We know we have all this data, but we don't know what we will
want to do with it later.  So keep it all.  I'll get back to you when
I want to know something."

It'd be nice to be able to load up all that data once, and then shunt
it off into (say) read-only media.  If one could then run a query
that would tell one which spans of data are candidates for the
search, you could bring back online (onto reasonably fast storage,
for instance) just the volumes you need to read.

A

-- 
Andrew Sullivan  | ajs@crankycanuck.ca
Users never remark, "Wow, this software may be buggy and hard 
to use, but at least there is a lot of code underneath."    --Damien Katz


pgsql-hackers by date:

Previous
From: "Simon Riggs"
Date:
Subject: Re: Deadlock with pg_dump?
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Multiple Storage per Tablespace, or Volumes