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
