Re: slowest tap tests - split or accelerate?

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: slowest tap tests - split or accelerate?
Дата
Msg-id 20220118214040.v74jalepfroqzpi7@alap3.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>)
Список pgsql-hackers
Hi,

On 2022-01-18 12:49:16 -0500, Robert Haas wrote:
> Here's a patch that splits up that file.

Ah, nice! The split seems sensible to me.


> Sadly, we've gained about 2.5 seconds of runtime as the price of
> splitting the test. Arguably the options part could be split up a lot
> more finely than this, but that would drive up the runtime even more,
> basically because we'd need more initdbs. So I don't know whether it's
> better to leave things as they are, split them this much, or split
> them more. I think this amount of splitting might be justified simply
> in the interests of clarity, but I'm reluctant to go further unless we
> get some nifty initdb-caching system.

Hm. From the buildfarm / CF perspective it might still be a win, because the
different pieces can run concurrently. But it's not great :(.

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.

Greetings,

Andres Freund



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

Предыдущее
От: James Coleman
Дата:
Сообщение: Re: Add last commit LSN to pg_last_committed_xact()
Следующее
От: David Steele
Дата:
Сообщение: Re: Allow root ownership of client certificate key