Re: Expose checkpoint start/finish times into SQL.
От | Theo Schlossnagle |
---|---|
Тема | Re: Expose checkpoint start/finish times into SQL. |
Дата | |
Msg-id | 99E74F97-99C1-4EF3-A555-7DC710710BC4@omniti.com обсуждение исходный текст |
Ответ на | Re: Expose checkpoint start/finish times into SQL. (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: Expose checkpoint start/finish times into SQL.
Re: Expose checkpoint start/finish times into SQL. |
Список | pgsql-patches |
On Apr 3, 2008, at 7:08 PM, Andrew Dunstan wrote: > > > Joshua D. Drake wrote: >>> Theo Schlossnagle wrote: >>> >>>> First whack at exposing the start and finish checkpoint times into >>>> SQL. >>>> >>> Why is that useful? >>> >> >> For knowing how long checkpoints are taking. If they are taking too >> long you may need to adjust your bgwriter settings, and it is a >> serious drag to parse postgresql logs for this info. >> >> >> > > Even if this were true, surely the answer is to improve the logging. > > Has this feature been discussed on -hackers? I don't recall it (and > my memory has plenty of holes in it), but I'm sure that after > attending my talk last Sunday Theo hasn't sent in a patch for an > undiscussed feature ;-) Andrew: I don't think this feature has been discussed on hackers. The patch took about 15 minutes to author, so it sounds like the most concise way to start a conversation. Seems silly to start the conversation on hackers with a patch. :-) Alvaro: Thanks, I flip that to GetCurrentTimestamp() Heikki: It it useful for knowing when the last checkpoint occurred. Like Robert, we have situations where reading the log file is a PITA -- so this provides that information. I originally planned on only adding the start time, but figured adding the end would make sense too. Tom: It worked for me in my testing, though I did not extensively tested. I didn't see anywhere the stats are zero'd out, so I believe the timestamp is zero at start and then only ever set to the starttime during a checkpoint invocation. I admittedly don't have a thorough understanding of that code -- but that segment (before my patch) looked pretty concise. -- Theo Schlossnagle Esoteric Curio -- http://lethargy.org/ OmniTI Computer Consulting, Inc. -- http://omniti.com/
В списке pgsql-patches по дате отправления: