On Sun, Nov 14, 2010 at 7:04 PM, Greg Smith <greg@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