Re: Expose checkpoint start/finish times into SQL.
От | Tom Lane |
---|---|
Тема | Re: Expose checkpoint start/finish times into SQL. |
Дата | |
Msg-id | 791.1207276395@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Expose checkpoint start/finish times into SQL. (Robert Treat <xzilla@users.sourceforge.net>) |
Ответы |
Re: Expose checkpoint start/finish times into SQL.
Re: Expose checkpoint start/finish times into SQL. |
Список | pgsql-patches |
Robert Treat <xzilla@users.sourceforge.net> writes: >> Tom Lane <tgl@sss.pgh.pa.us> wrote: > 3. As of PG 8.3, the bgwriter tries very hard to make the elapsed time > of a checkpoint be just about checkpoint_timeout * > checkpoint_completion_target, regardless of load factors. So unless > your settings are completely broken, measuring the actual time isn't > going to tell you much. > How does one measure when the bgwriter is failing at this effort? Well, not with *this* patch. At least not without adding a lot of infrastructure on top of it, and I'm failing to see why you'd build such infrastructure in order to track just two numbers that are of uncertain value. JD seems to be on record that the existing logging mechanism sucks and he needs something else. That's fine, but I think it means that we need to improve logging in general, not invent a single-purpose mechanism for logging checkpoint times. Theo claimed he had a reason for wanting to know the latest checkpoint time, *without* any intention of time-extended tracking of that; but he didn't say what it was. If there is a credible reason for that then it might justify a patch of this nature, but I don't see that the reasons that have been stated so far in the thread hold any water. regards, tom lane
В списке pgsql-patches по дате отправления: