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.
--
Robert Haas
EDB: http://www.enterprisedb.com
