On Mon, Feb 19, 2007 at 11:25:41AM +0100, Dimitri Fontaine wrote:
> Hi list,
> Here's a proposal of this idea which stole a good part of my night.
> I'll present first the idea, then 2 use cases where to read some rational and 
> few details. Please note I won't be able to participate in any development 
> effort associated with this idea, may such a thing happen!
> The bare idea is to provide a way to 'attach' multiple storage facilities 
> (say 
> volumes) to a given tablespace. Each volume may be attached in READ ONLY, 
> You can mix RW and WO volumes into the same tablespace, but can't have RO 
> with 
> any W form, or so I think.

Somehow this seems like implementing RAID within postgres, which seems
a bit outside of the scope of a DB.

> Use Case A: better read performances while keeping data write reliability
> The first application of this multiple volumes per tablespace idea is to keep 
> a tablespace both into RAM (tmpfs or ramfs) and on disk (both RW).

For example, I don't beleive there is a restiction against having one
member of a RAID array being a RAM disk.

> Use Case B: Synchronous Master Slave(s) Replication
> By using a Distributed File System capable of being mounted from several 
> nodes 
> at the same time, we could have a configuration where a master node has 
> ('exports') a WO tablespace volume, and one or more slaves (depending on FS 
> capability) configures a RO tablespace volume.

Here you have the problem of row visibility. The data in the table isn't
very useful without the clog, and that's not stored in a tablespace...

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.

Attachment: signature.asc
Description: Digital signature

Reply via email to