Hi,
Chris Browne wrote:
Under conditions where one expects to see a lot of conflicting
updates, pushing out locks earlier would allow sooner discovery of
these conflicts; whether this improves or worsens total performance is
at least a bit ambiguous.
That's a good point, yes. Given one gets lots of conflicts, one should
probably go for async (or single master) replication anyway. (Or see the
performance degrade below single-node operation, which is imaginable for
both approaches, IMHO. Finally, only benchmarking will tell.)
[ In single node operation, we have READ COMMITTED vs. SERIALIZABLE,
which is pessimistic vs. optimistic. Correct me if I'm wrong, but in
general I thought, optimistic locking (SERIALIZABLE) is prefered and
leads to better performance. That's why came to think the same holds
true for replication. Or is READ COMMITTED better if you have lots of
conflicting transactions? Any numbers on that? ]
Coming back to thinking about the replicaiton doc... the draft describes
the different types of replication very well. But no all users will
immediately see what each type is good for. Therefore we should probably
also cover some use cases, i.e. what type of replication to use when.
The most frequently asked use case probably being a hot-backup with
failover capability -> single-master, async / sync, depending on your
needs. Another use case could probably describe a multi-master scenario
and outline pros and cons of that (perhaps gently touching the above issue?)
Another issue that comes to mind: PgCluster2 targets shared-disk
clusters, a significant difference to shared-nothing clusters. Maybe
that gives another paragraph under 'categorization'?
Given that additional categorization: should the use cases be added per
replication solution?
A nit-picking detail: I'm unsure about the correct english spelling of
single- and multi-master ('single master', 'single-master' or
'singlemaster'), but please make sure to use a consistent spelling.
That is indeed useful editorial guidance...
Sorry, I must have felt super clever. ;-) Although... as a non native
english speaker, I would still like to know the preferred spelling.
Regards
Markus
---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
