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 <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to
> litigate.
signature.asc
Description: Digital signature
