Feedback-ID: id4a34324:Fastmail
Date: Wed, 25 Mar 2026 12:13:08 -0400
From: Andres Freund <andres@anarazel.de>
To: Tomas Vondra <tomas@vondra.me>
Cc: pgsql-hackers@postgresql.org, Dilip Kumar <dilipbalaut@gmail.com>,
	Jelte Fennema-Nio <postgres@jeltef.nl>,
 Thomas Munro <thomas.munro@gmail.com>,
	Noah Misch <noah@leadboat.com>
Subject: Re: Test timings are increasing too fast for cfbot
Message-ID: <ggrz726w3y2umzgrfybvbemkfkeedyjspikzlfnifyw4rvd3oz@inhcgrbasohs>
References: <mtkrkkcn2tlhytumitpch5ubxiprv2jzvprf5r5m3mjeczvq4q@p6wkzbfxuyv2>
 <ogohyk54vjyejn3kdibrc73wcrdhwsq57fawxitycen6ntbzo3@gnnwuagu2qqj>
 <753e7734-95d9-45d3-85d9-a53638b1b3dd@vondra.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <753e7734-95d9-45d3-85d9-a53638b1b3dd@vondra.me>
Archived-At: 
 <https://www.postgresql.org/message-id/ggrz726w3y2umzgrfybvbemkfkeedyjspikzlfnifyw4rvd3oz%40inhcgrbasohs>
Precedence: bulk

Hi,

On 2026-03-25 15:38:01 +0100, Tomas Vondra wrote:
> On 3/25/26 04:15, Andres Freund wrote:
> > ...
> > 
> > The slowest test is stats_ext.sql - Not surprising, it does sequential scans
> > of tables with ~1000-10000 rows over and over again.  I don't see why it has
> > to do that with as many rows as it does.
> > 
> 
> IIRC we needed to use non-trivial amounts of data to ensure building the
> right right type of statistics (e.g. no MCV). But I understand it can be
> annoyingly expensive, so I'll try to make it cheaper.

Great.  It might also be worth checking if any of the query conditions can be
made cheaper without actually changing what they do test.


> >  ...
> > 2) AssertCheckRanges() (only in the brin test, but there a very large portion
> >    of the runtime)
> 
> True. It is a very comprehensive validation of the ranges, and it was
> very useful - particularly during development. But I'll try to make it
> more targeted at the stuff actually changed / called less often.

Makes sense.  There might also be some changs that make it faster without
loosing any coverage. E.g. not using FunctionCall2Coll() - which initializes
stuff on every call - but doing InitFunctionCallInfoData() once and then
update arguments + FunctionCallInvoke() for each call.


> Both changes will require time (so that we don't lose test coverage),
> but I assume it's OK if that happens sometime after the feature freeze.

Yea. We're not running out of credits tomorrow or something like that.

Greetings,

Andres Freund