Re: Patch: add timing of buffer I/O requests
От | Greg Stark |
---|---|
Тема | Re: Patch: add timing of buffer I/O requests |
Дата | |
Msg-id | CAM-w4HPS-im5aH2FCyHHhcN4RgNm8uCE4X464BCmDFwG3t+KVw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Patch: add timing of buffer I/O requests (Greg Smith <greg@2ndQuadrant.com>) |
Ответы |
Re: Patch: add timing of buffer I/O requests
|
Список | pgsql-hackers |
<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 />
В списке pgsql-hackers по дате отправления: