Re: REVIEW: Track TRUNCATE via pgstat - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: REVIEW: Track TRUNCATE via pgstat
Date
Msg-id 20141216140156.GV1768@alvh.no-ip.org
Whole thread Raw
In response to Re: REVIEW: Track TRUNCATE via pgstat  (Alex Shulgin <ash@commandprompt.com>)
Responses Re: REVIEW: Track TRUNCATE via pgstat  (Alex Shulgin <ash@commandprompt.com>)
List 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 by date:

Previous
From: "Timmer, Marius"
Date:
Subject: Re: [PATCH] explain sortorder
Next
From: Heikki Linnakangas
Date:
Subject: Re: WALWriter active during recovery