From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
cc: pgsql-hackers@postgresql.org
Subject: Re: Reducing runtime of stats regression test
In-reply-to: <20170504135449.zepyxepq6ug5pgim@alvherre.pgsql>
References: <20170504135449.zepyxepq6ug5pgim@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
	message dated "Thu, 04 May 2017 10:54:49 -0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7129.1493907721.1@sss.pgh.pa.us>
Date: Thu, 04 May 2017 10:22:01 -0400
Message-ID: <7130.1493907721@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Tom Lane wrote:
>> We can just start a new connection with \c, and
>> let wait_for_stats wait for the old one to send its stats before quitting.
>> Even on my oldest and slowest buildfarm machines, starting a new session
>> takes well under one second.

> So you changed table prevstats from temp to permanent;

Right, so it would survive into the new session.

> perhaps make it unlogged?

Hardly seems worth it; there's not much data in it.  And we're not
generally in the habit of marking short-lived tables as unlogged
elsewhere in the regression tests.  (Maybe we should make some
effort to have some of them be so marked, but that seems like
material for its own patch.)

> I wonder if it'd be useful to have a "pg_stat_flush" or something, which
> sends out whatever is queued in this session.  Then you wouldn't need
> the reconnection.

Yes, but that would be getting into the realm of new features, not
post-feature-freeze test adjustments.  It certainly couldn't be
a candidate for back-patching.

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers