| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
| Cc: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Anastasia Lubennikova <lubennikovaav(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: A test for replay of regression tests |
| Date: | 2022-01-27 20:47:08 |
| Message-ID: | 20220127204708.4ktz6frqg43yg4uo@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2022-01-27 15:27:17 -0500, Andrew Dunstan wrote:
> fairywren is not happy with the recovery tests still.
Any more details?
> I have noticed on a different setup that this test adds 11 minutes to the
> runtime of the recovery tests, effectively doubling it. The doubling is
> roughly true on faster setups, too
Does a normal regress run take roughly that long? Or is the problem that the
027_stream_regress.pl ends up defaulting to shared_buffers=1MB, causing lots
of unnecessary IO?
> . At least I would like a simple
> way to disable the test.
One thing we could do to speed up the overall runtime would be to move
027_stream_regress.pl to something numbered earlier. Combined with
PROVE_FLAGS=-j2 that could at least run them in parallel with the rest of the
recovery tests.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Imseih (AWS), Sami | 2022-01-27 21:09:05 | Re: Add index scan progress to pg_stat_progress_vacuum |
| Previous Message | Thomas Munro | 2022-01-27 20:41:04 | Re: Creation of an empty table is not fsync'd at checkpoint |