On Sun, Nov 14, 2010 at 7:04 PM, Greg Smith <g...@2ndquadrant.com> wrote: > It might. One trade-off is that if you're looking at the sync write detail, > the summary comes out in a similar form. And it was easy to put in > here--I'd have to return some new data out of the sync phase call in order > for that to show up in the main log. If there's general buy-in on the idea, > I could do all of that.
+1 for that approach. > What I was alluding to is that I know gettimeofday executes fast on my Linux > system here, so even if I did measure the overhead and showed it's near zero > that doesn't mean it will be so on every platform. The "how long does it > take to find out the current time on every supported PostgreSQL platform?" > question is one I'd like to have an answer to, but it's hard to collect > properly. All I know is that I don't have any system where it's slow to > properly test again here. I would be very surprised if we can find a system where gettimeofday() takes a significant amount of time compared with fsync(). It might be (probably is) too expensive to stick into code paths that are heavily CPU-bounded, but surely the cost here is going to be dwarfed by the fsync(), no? Unless maybe there's no I/O to be done anyway, but that case doesn't seem important to optimize for. I think making this code dependent on ifdef DEBUG_FSYNC is going to make in order of magnitude less useful, so I'd really rather not do that unless we have some hard evidence that there is a real problem to worry about here. Making it conditional on log_checkpoints seems entirely sufficient to me. -- 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
