Re: Run pg_amcheck in 002_pg_upgrade.pl and 027_stream_regress.pl?
От | Andres Freund |
---|---|
Тема | Re: Run pg_amcheck in 002_pg_upgrade.pl and 027_stream_regress.pl? |
Дата | |
Msg-id | 20220405003958.a4aygou72d3tmwgy@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Run pg_amcheck in 002_pg_upgrade.pl and 027_stream_regress.pl? (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Run pg_amcheck in 002_pg_upgrade.pl and 027_stream_regress.pl?
|
Список | pgsql-hackers |
Hi, On 2022-04-05 08:46:06 +0900, Michael Paquier wrote: > On Sun, Apr 03, 2022 at 11:53:03AM -0700, Andres Freund wrote: > > It seems $subject would have a chance of catching some of these bugs, as well > > as exposing amcheck to a database with a bit more varied content? > > Makes sense to me to extend that. > > > Depending on the cost it might make sense to do this optionally, via > > PG_TEST_EXTRA? > > Yes, it would be good to check the difference in run-time before > introducing more. A logical dump of the regression database is no > more than 15MB if I recall correctly, so my guess is that most of the > runtime is still going to be eaten by the run of pg_regress. On my workstation it takes about 2.39s to run pg_amcheck on a regression database with all thoroughness options enabled. With -j4 it's 0.62s. Without more thorough checking it's 1.24s and 0.30s with -j4. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: