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