Re: Instrument checkpoint sync calls

Поиск
Список
Период
Сортировка
От Greg Smith
Тема Re: Instrument checkpoint sync calls
Дата
Msg-id 4CE07928.3010507@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: Instrument checkpoint sync calls  (Magnus Hagander <magnus@hagander.net>)
Ответы Re: Instrument checkpoint sync calls  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Magnus Hagander wrote:<br /><blockquote cite="mid:AANLkTi=prse2HvBnaj5Amzf9zZq7izNPs0APwx1MP-5z@mail.gmail.com"
type="cite"><blockquotetype="cite"><pre wrap="">
 
I think that it's reasonable for the sort of people who turn log_checkpoints
on to also get the sync summary line, thus it being logged at LOG level.   </pre></blockquote><pre wrap="">
In that case, wouldn't it make more sense to add a couple of more
fields to the existing line? Easier to post-process the logfile that
way... </pre></blockquote><br /> It might.  One trade-off is that if you're looking at the sync write detail, the
summarycomes out in a similar form.  And it was easy to put in here--I'd have to return some new data out of the sync
phasecall in order for that to show up in the main log.  If there's general buy-in on the idea, I could do all of
that.<br/><br /><br /><blockquote cite="mid:AANLkTi=prse2HvBnaj5Amzf9zZq7izNPs0APwx1MP-5z@mail.gmail.com"
type="cite"><blockquotetype="cite"><pre wrap="">I personally think that if you're
 
already making an fsync call and have log_checkpoints on, the additional
overhead of also timing that fsync is minimal even on platforms where timing
is slow (I don't have such a system to test that assumption however)...</pre></blockquote><pre wrap="">
It sounds like it should be - but that should be possible to measure, no? </pre></blockquote><br /> What I was alluding
tois that I know gettimeofday executes fast on my Linux system here, so even if I did measure the overhead and showed
it'snear zero that doesn't mean it will be so on every platform.  The "how long does it take to find out the current
timeon every supported PostgreSQL platform?" question is one I'd like to have an answer to, but it's hard to collect
properly. All I know is that I don't have any system where it's slow to properly test again here.<br /><br /><pre
class="moz-signature"cols="72">-- 
 
Greg Smith   2ndQuadrant US    <a class="moz-txt-link-abbreviated"
href="mailto:greg@2ndQuadrant.com">greg@2ndQuadrant.com</a>  Baltimore, MD
 
PostgreSQL Training, Services and Support        <a class="moz-txt-link-abbreviated"
href="http://www.2ndQuadrant.us">www.2ndQuadrant.us</a>

</pre>

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Joachim Wieland
Дата:
Сообщение: WIP patch for parallel pg_dump
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Per-column collation