Re: REVIEW: Track TRUNCATE via pgstat

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: REVIEW: Track TRUNCATE via pgstat
Дата
Msg-id 20141216140156.GV1768@alvh.no-ip.org
обсуждение исходный текст
Ответ на Re: REVIEW: Track TRUNCATE via pgstat  (Alex Shulgin <ash@commandprompt.com>)
Ответы Re: REVIEW: Track TRUNCATE via pgstat  (Alex Shulgin <ash@commandprompt.com>)
Список pgsql-hackers
Alex Shulgin wrote:
> Jim Nasby <Jim.Nasby@BlueTreble.com> writes:

> > The test also adds 2.5 seconds of forced pg_sleep. I think that's both
> > bad and unnecessary. When I removed the sleeps I still saw times of
> > less than 0.1 seconds.
> 
> Well, I never liked that part, but the stats don't get updated if we
> don't put the session to sleep for at least PGSTAT_STAT_INTERVAL (which
> is 500ms).
> 
> Removing these extra sleep calls would theoretically not make a
> difference as wait_for_trunc_test_stats() seems to have enough sleep
> calls itself, but due to the pgstat_report_stat() being called from the
> main loop only, there's no way short of placing the explicit pg_sleep at
> top level, if we want to be able to check the effects reproducibly.
> 
> Another idea would be exposing pgstat_report_stat(true) at SQL level.
> That would eleminate the need for explicit pg_sleep(>=0.5), but we'll
> still need the wait_for_... call to make sure the collector has picked
> it up.

We already have a stats test that sleeps.  Why not add this stuff there,
to avoid making another test slow?

I agree that tests that sleep are annoying.  (Try running the "timeout"
isolation test a few times and you'll see what I mean.)

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



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

Предыдущее
От: "Timmer, Marius"
Дата:
Сообщение: Re: [PATCH] explain sortorder
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: Re: WALWriter active during recovery