On 06/21/2011 01:25 PM, David Fetter wrote:
Dynamically generated tables are generally a problem at the design
level. Neither PostgreSQL nor any other engine will solve that.
It depends a bit on what the OP means by dynamically generated tables.
I'm not entirely sure what you mean by a "clustered scenario,"
... which is really important.
You need to define your needs better. Why are you clustering? What
problems is your cluster intended to solve? Is it for performance?
Redundancy? Geographic distribution of replicas? Can you afford to lose
a certain limited number/time of transactions if the master fails, or
must absolutely every transaction be replicated to standby nodes before
a COMMIT returns success to the application? Do query results from
standby nodes have to be perfectly consistent with the master, or can
they lag behind? Do you need to be able to write changes to multiple
nodes, or is it OK to have a single master node for writes and multiple
nodes for read-only queries?
BTW, I cannot agree enough with David Fetter's comments on multiple
master replication - so long as it's qualified with "in relational
databases". Multiple master works extremely well when used with systems
designed for it like eventually-consistent distributed document
databases. It works relatively poorly for SQL RDBMSs because there's so
much inter-node synchronization and co-ordination required to keep
everything consistent and correct according to the strict rules of the
SQL standards.
--
Craig Ringer
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
