slowest tap tests - split or accelerate?
От
Andres Freund
Тема
slowest tap tests - split or accelerate?
Дата
Msg-id
20211231192528.wirwj4qaaw3ted5g@alap3.anarazel.de
Список
Дерево обсуждения
slowest tap tests - split or accelerate? Andres Freund <andres@anarazel.de>
Re: slowest tap tests - split or accelerate? Andres Freund <andres@anarazel.de>
Re: slowest tap tests - split or accelerate? Robert Haas <robertmhaas@gmail.com>
Re: slowest tap tests - split or accelerate? Andres Freund <andres@anarazel.de>
Re: slowest tap tests - split or accelerate? Tom Lane <tgl@sss.pgh.pa.us>
Re: slowest tap tests - split or accelerate? Robert Haas <robertmhaas@gmail.com>
Re: slowest tap tests - split or accelerate? Andres Freund <andres@anarazel.de>
Re: slowest tap tests - split or accelerate? Andres Freund <andres@anarazel.de>
Re: slowest tap tests - split or accelerate? Tom Lane <tgl@sss.pgh.pa.us>
Re: slowest tap tests - split or accelerate? Andres Freund <andres@anarazel.de>
Re: slowest tap tests - split or accelerate? Tom Lane <tgl@sss.pgh.pa.us>
Re: slowest tap tests - split or accelerate? Andres Freund <andres@anarazel.de>
Re: slowest tap tests - split or accelerate? Andres Freund <andres@anarazel.de>
Re: slowest tap tests - split or accelerate? Andres Freund <andres@anarazel.de>
initdb caching during tests Andres Freund <andres@anarazel.de>
Re: initdb caching during tests Tom Lane <tgl@sss.pgh.pa.us>
Re: initdb caching during tests Andres Freund <andres@anarazel.de>
Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
Re: initdb caching during tests Andres Freund <andres@anarazel.de>
Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
Re: initdb caching during tests Andres Freund <andres@anarazel.de>
Re: initdb caching during tests Nathan Bossart <nathandbossart@gmail.com>
Re: initdb caching during tests Thomas Munro <thomas.munro@gmail.com>
Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
Re: initdb caching during tests Andres Freund <andres@anarazel.de>
Re: initdb caching during tests Matthias van de Meent <boekewurm+postgres@gmail.com>
Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
Re: initdb caching during tests Matthias van de Meent <boekewurm+postgres@gmail.com>
Re: initdb caching during tests Daniel Gustafsson <daniel@yesql.se>
Re: slowest tap tests - split or accelerate? Andrew Dunstan <andrew@dunslane.net>
Re: slowest tap tests - split or accelerate? Robert Haas <robertmhaas@gmail.com>
Re: slowest tap tests - split or accelerate? Andres Freund <andres@anarazel.de>
Hi, cfbot now runs most tests on windows, the windows task is by far the slowest, and the task limitted most in concurrency [2]. Running tap tests is the biggest part of that. This is a bigger issue on windows because we don't have infrastructure (yet) to run tests in parallel. There's a few tests which stand out in their slowness, which seem worth addressing even if we tackle test parallelism on windows at some point. I often find them to be the slowest tests on linux too. Picking a random successful cfbot run [1] I see the following tap tests taking more than 20 seconds: 67188 ms pg_basebackup t/010_pg_basebackup.pl 59710 ms recovery t/001_stream_rep.pl 57542 ms pg_rewind t/001_basic.pl 56179 ms subscription t/001_rep_changes.pl 42146 ms pgbench t/001_pgbench_with_server.pl 38264 ms recovery t/018_wal_optimize.pl 33642 ms subscription t/013_partition.pl 29129 ms pg_dump t/002_pg_dump.pl 25751 ms pg_verifybackup t/002_algorithm.pl 20628 ms subscription t/011_generated.pl It would be good if we could make those tests faster, or if not easily possible, at least split those tests into smaller tap tests. Splitting a longer test into smaller ones is preferrable even if they take the same time, because we can use prove level concurrency on windows to gain some test parallelism. As a nice side-effect it makes it also quicker to run a split test isolated during development. Greetings, Andres Freund [1] https://cirrus-ci.com/task/5207126145499136 [2] https://cirrus-ci.org/faq/#are-there-any-limits
В списке pgsql-hackers по дате отправления
От: Rémi Lapeyre
Дата: