Re: REVIEW: Track TRUNCATE via pgstat

Alex Shulgin wrote:
> Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)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