Re: Synchronization levels in SR
От | Simon Riggs |
---|---|
Тема | Re: Synchronization levels in SR |
Дата | |
Msg-id | 1283812445.1834.11007.camel@ebony обсуждение исходный текст |
Ответ на | Re: Synchronization levels in SR (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: