On Sat, Jan 15, 2011 at 5:57 PM, Greg Smith <g...@2ndquadrant.com> wrote: > I was just giving an example of how I might do an initial split. There's a > checkpoint happening now at time T; we have a rough idea that it needs to be > finished before some upcoming time T+D. Currently with default parameters > this becomes: > > Write: 0.5 * D; Sync: 0 > > Even though Sync obviously doesn't take zero. The slop here is enough that > it usually works anyway. > > I was suggesting that a quick reshuffling to: > > Write: 0.4 * D; Sync: 0.4 * D > > Might be a good first candidate for how to split the time up better.
What is the basis for thinking that the sync should get the same amount of time as the writes? That seems pretty arbitrary. Right now, you're allowing 3 seconds per fsync, which could be a lot more or a lot less than 40% of the total checkpoint time, but I have a pretty clear sense of why that's a sensible thing to try: you give the rest of the system a moment or two to get some I/O done for something other than the checkpoint before flushing the next batch of buffers. But the checkpoint activity is always going to be spikey if it does anything at all, so spacing it out *more* isn't obviously useful. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
