| From: | Richard Huxton <dev(at)archonet(dot)com> |
|---|---|
| To: | Heikki Linnakangas <heikki(at)enterprisedb(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Group Commit |
| Date: | 2007-03-26 11:03:08 |
| Message-ID: | 4607A86C.4050506@archonet.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Teodor Sigaev | 2007-03-26 11:10:05 | Re: tsearch2 regression test failures |
| Previous Message | Magnus Hagander | 2007-03-26 10:58:21 | Re: tsearch2 regression test failures |