On Mon, 2010-09-06 at 16:11 -0400, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > On Mon, 2010-09-06 at 21:45 +0200, Boszormenyi Zoltan wrote:
> >> The locks held by a transaction are released after
> >> RecordTransactionCommit(), and waiting for the sync ack
> >> happens in this function. Now what happens when a sync
> >> transaction hold a lock that an async one is waiting for?
>
> > It seems your glass in half-empty. Mine is half-full.
>
> Simon, you really are failing to advance the conversation. You claim
> that we can have sync plus async transactions without a performance hit,
> but you have failed to explain how, at least in any way that anyone
> else understands. Pontificating about how that will be so much better
> than not having it doesn't address the problem that others are having
> with seeing how to implement it.
A performance hit from mixing sync and async is unlikely. The overhead
of deciding whether to wait after commit is trivial. At worst, the async
transactions would go at the same speed as the sync transactions,
especially if the application contends with itself, which is by no means
a certainty. If acting independently, the async transactions would
clearly go much faster. So the right question for discussion is "how
much will we gain by mixing async/sync?". Since we had exactly this
situation for synchronous_commit and a similar discussion, I expect a
similar eventual outcome.
The discussion would go better if we had clear performance results
published from existing work and we did not dissuade people from
objective testing. Then you'd probably understand why I think this is so
important to me.
I've explained more than once how my proposal can work and Dimitri at
least appears to have understood with zero off-list conversation. So far
the discussion has been mostly negative and the reasons given haven't
scored high on logic, I'm sorry to say. I will present a code-based
proposal rather than just huge piles of words, to make this a more
concrete discussion.
-- Simon Riggs www.2ndQuadrant.com
