Hi,
On 09/07/2010 06:00 PM, Robert Haas wrote:
> People who are more concerned about performance than robustness aren't
> going to use sync rep in the first place.
I'm advocating sync (or eager, FWIW) replication for years, now. One of
the hardest preconception I'm always confronted with is: this must
perform poorly!
Whether or not that's true depends, but my point is: people who need
that level of robustness certainly care about performance as well.
Telling them to use async replication instead is not an option. (The
ability to mix sync and async replication per transaction is one, BTW).
> They're going to run it in
> async, which will improve performance by FAR more than you'll ever be
> able to manage by deciding that you don't care about handling some of
> the failure cases correctly.
Running in async and then trying to achieve the required level of
robustness in the application layer pretty certainly performs worse than
a good sync replication implementation. Async only wins if you really
don't care about the loss of transactions in the case of a failure. In
every other case, robustness is better taken care of by the database
system itself, IMO.
That being said, I certainly agree to do things step by step. And the
ability to write to WAL and wait for ack from a standby concurrently can
(and probably should) be considered an optimization, yes.
Regards
Markus Wanner