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, > READ WRITE or WRITE ONLY mode. > 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 <email@example.com> http://svana.org/kleptog/ > From each according to his ability. To each according to his ability to > litigate.
Description: Digital signature