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 по дате отправления:

Предыдущее
От: Jeff Davis
Дата:
Сообщение: Re: Extensible Rmgr for Table AMs
Следующее
От: Peter Smith
Дата:
Сообщение: Re: Handle infinite recursion in logical replication setup