On 2/17/22 10:36, Robert Haas wrote:
> On Wed, Feb 16, 2022 at 2:50 PM Andres Freund <andres@anarazel.de> wrote:
>>> initdb is already plenty fast enough for any plausible production
>>> usage; it's cases like check-world where we wish it were faster.
>> It's not just our own usage though. I've seen it be a noticable time in test
>> suites of applications using postgres.
> I'd just like to second this point.
>
> I was working on an EDB proprietary software project for a while
> which, because of the nature of what it did, ran initdb frequently in
> its test suite. And it was unbelievably painful. The test suite just
> took forever. Fortunately, it always ran initdb with the same options,
> so somebody invented a mechanism for doing one initdb and saving the
> results someplace and just copying them every time, and it made a huge
> difference. Before that experience, I probably would have agreed with
> the idea that there was no need at all for initdb to be any faster
> than it is already. But, like, what if we'd been trying to run initdb
> with different options for different tests, the way the core code
> does? That seems like an entirely plausible thing to want to do, and
> then caching becomes a real pain.
Indeed. When initdb.c was written the testing landscape was very
different both for the community and for projects that used Postgres. So
we need to catch up.
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
