From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Greg Smith <greg(at)2ndquadrant(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Instrument checkpoint sync calls |
Date: | 2010-11-15 19:48:21 |
Message-ID: | 5308.1289850501@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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'm not sure I buy that --- the whole point of spread checkpoints is
that we hope the I/O happens before we actually call fsync.
> Making it
> conditional on log_checkpoints seems entirely sufficient to me.
But I'll agree with that. If you're turning on log_checkpoints then
you've given the system permission to indulge in extra overhead for
monitoring.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Smith | 2010-11-15 20:09:31 | Re: Instrument checkpoint sync calls |
Previous Message | Peter Eisentraut | 2010-11-15 19:42:37 | Re: Per-column collation |