On Wed, Feb 16, 2022 at 2:50 PM Andres Freund <and...@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
