Re: slowest tap tests - split or accelerate?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: slowest tap tests - split or accelerate?
Дата
Msg-id 540868.1642611241@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>)
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2022-01-18 13:40:40 -0800, Andres Freund wrote:
>> Maybe we really should do at least the most simplistic caching for initdbs, by
>> doing one initdb as part of the creation of temp_install. Then Cluster::init
>> would need logic to only use that if $params{extra} is empty.

> I hacked this together. And the wins are bigger than I thought.

Me too ;-).  As I remarked earlier, I'd tried this once before and
gave up because it didn't seem to be winning much.  But that was
before we had so many initdb's triggered by TAP tests, I think.

I tried this patch on florican's host, which seems mostly disk-bound
when doing check-world.  It barely gets any win from parallelism:

$ time make -s check-world -j1 >/dev/null
     3809.60 real       584.44 user       282.23 sys
$ time make -s check-world -j2 >/dev/null
     3789.90 real       610.60 user       289.60 sys

Adding v2-0001-hack-use-template-initdb-in-tap-tests.patch:

$ time make -s check-world -j1 >/dev/null
     3193.46 real       221.32 user       226.11 sys
$ time make -s check-world -j2 >/dev/null
     3211.19 real       224.31 user       230.07 sys

(Note that all four runs have the "fsync = on" removed from
008_fsm_truncation.pl.)

So this looks like it'll be a nice win for low-end hardware, too.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Replace uses of deprecated Python module distutils.sysconfig
Следующее
От: Andres Freund
Дата:
Сообщение: Re: slowest tap tests - split or accelerate?