<p><br /> On Nov 28, 2011 8:55 AM, "Greg Smith" <<a href="mailto:greg@2ndquadrant.com">greg@2ndquadrant.com</a>>
wrote:<br/> ><br /> > On 11/27/2011 04:39 PM, Ants Aasma wrote:<br /> >><br /> >> On the AMD I saw
about3% performance drop with timing enabled. On the<br /> >> Intel machine I couldn't measure any statistically
significantchange.<br /> ><br /> ><br /> > Oh no, it's party pooper time again. Sorry I have to be the one to
doit this round. The real problem with this whole area is that we know there are systems floating around where the
amountof time taken to grab timestamps like this is just terrible. <p>I believe on most systems on modern linux kernels
gettimeofdayan its ilk will be a vsyscall and nearly as fast as a regular function call.<br /><p>><br /> > I
recalla patch similar to this one was submitted by Greg Stark some time ago. It used the info for different
reasons--totry and figure out whether reads were cached or not--but I believe it withered rather than being implemented
mainlybecause it ran into the same fundamental roadblocks here. My memory could be wrong here, there were also
concernsabout what the data would be used for.<p>I speculated about doing that but never did. I had an experimental
patchusing mincore to do what you describe but it wasn't intended for production code I think. The only real patch was
touse getrusage which I still intend to commit but it doesn't tell you the time spent in I/O -- though it does tell you
thesys time which should be similar.<br />