On 9/15/24 21:47, Tomas Vondra wrote:
> On 9/15/24 20:31, Tom Lane wrote:
>> Tomas Vondra writes:
>>> [ 002_pg_upgrade and 027_stream_regress are slow ]
>>
>>> I don't have a great idea how to speed up these tests, unfortunately.
>>> But one of the problems is that all the TAP tests run serially
Thomas Munro writes:
> (An interesting archeological detail about the regression tests is
> that they seem to derive from the Wisconsin benchmark, famous for
> benchmark wars and Oracle lawyers[1].
This is quite off-topic for the thread, but ... we actually had an
implementation of the Wisconsin
On Mon, Sep 16, 2024 at 6:31 AM Tom Lane wrote:
> Really the way to fix those two tests would be to rewrite them to not
> depend on the core regression tests. The core tests do a lot of work
> that's not especially useful for the purposes of those tests, and it's
> not even clear that they are ex
On 9/15/24 20:31, Tom Lane wrote:
> Tomas Vondra writes:
>> [ 002_pg_upgrade and 027_stream_regress are slow ]
>
>> I don't have a great idea how to speed up these tests, unfortunately.
>> But one of the problems is that all the TAP tests run serially - one
>> after each other. Could we instead r
Tomas Vondra writes:
> [ 002_pg_upgrade and 027_stream_regress are slow ]
> I don't have a great idea how to speed up these tests, unfortunately.
> But one of the problems is that all the TAP tests run serially - one
> after each other. Could we instead run them in parallel? The tests setup
> the
Hi,
I've been doing a lot of tests under valgrind lately, and it made me
acutely aware of how long check-world takes. I realize valgrind is
inherently expensive and slow, and maybe the reasonable reply is to just
run a couple tests that are "interesting" for a patch ...
Anyway, I did a simple exp
