Heikki Linnakangas wrote:
Here's what's happening:

1. Client 1 issues fsync (A)
2. Clients 2-5 write their commit record, and try to fsync, but they have to wait for fsync (A) to finish.

It contains a graph that shows that the patch works very well for this test case. It's not very good for real life as it is, though. An obvious flaw is that if you have a longer-running transaction, effect 1. goes away. Instead of waiting for NBackends commit records, we should try to guess the number of transactions that are likely to finish in a reasonably short time. I'm thinking of keeping a running average of commits per second, or # of transactions that finish while an fsync is taking place.

Any thoughts?

Well, you did say *any* thoughts, so I guess mine count :-)

Do you not want to minimise the cost of #2 in your sequence? Some measure of "total backend time spent waiting to commit".

I don't know how simple it is to measure/estimate the time spent for "# of transactions that finish while an fsync is taking place".

  Richard Huxton
  Archonet Ltd

---------------------------(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

Reply via email to