> It would only be possible to have the actual PostgreSQL backends > running on a single node anyway, because they use shared memory to
This is not problem: Performance is a secondary consideration (at least as far as the problem I was referring to). The primary usefulness is to have the data be a logical entity rather than a physical entity so that one can maintain physical machines without having to worry to much about where-is-the-data. At the moment, most databases suffer from the problem of occasionally having to move the data from one place to another. This is a major nightmare that happens once every few years for most DBAs. It happens because a system needs a soft/hard upgrade, or a disk enlarged, or because a piece of hardware fails. I have also found it's no use having RAID or ZFS. Each of these ties the data to an OS installation. If the OS needs to be reinstalled, all the data has to be manually moved in a way that is, well... dangerous. If there is only one machine running postgres that is fine too: I can have a second identical machine on standby in case of a hardware failure. That means a short amount of downtime - most people can live with that. I read somewhere that replication was one of the goals of postgres's coming development efforts. Personally I think hadoop might be a better solution - *shrug*. Thoughts/comments ?? -paul
