On 9/8/21 5:48 PM, Andres Freund wrote: > Hi, > > On September 8, 2021 1:24:00 PM PDT, Andrew Dunstan <and...@dunslane.net> > wrote: >> On 9/8/21 3:07 PM, Andres Freund wrote: >>> There of course is historical raisins for things happening in initdb - the >>> setup logic didn't use to be C. But now that it is C, it seems a bit absurd >>> to >>> read bootstrap data in initdb, write the data to a pipe, and then read it >>> again in the backend. It for sure doesn't make things faster. >> >> I guess the downside would be that we'd need to teach the backend how to >> do more stuff that only needs to be done once per cluster, and then that >> code would be dead space for the rest of the lifetime of the cluster. >> >> >> Maybe the difference is sufficiently small that it doesn't matter. > Unused code doesn't itself cost much - the OS won't even page it in. And disk > space wise, there's not much difference between code in initdb and code in > postgres. It's callsites to the code that can be problematic. But there were > already paying the price via --boot and a fair number of if (bootstrap) > blocks. >
Fair enough. You're quite right, of course, the original design of initdb.c was to do what the preceding shell script did as closely as possible. It does leak a bit of memory, which doesn't matter in the context of a short-lived program - but that shouldn't be too hard to manage in the backend. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
