> > > We add those to all links, mostly because it is too confusing to > > > do it per link. It doesn't hurt anything because it is > > > dynamically linked, so doesn't take any disk space, and in fact > > > is never called. > > > > My concern wasn't for disk space, but for symbol resolution times > > and unnecessary VM page table space. Does the backend fork() or > > exec() a copy of itself when a new connection comes in? I thought > > it was exec() for some reason. Anyway, given how easy it is to > > change the LDFLAGS, I was thinking about chasing down where > > postgres is linked and splitting apart LDFLAGS into two sets of > > LDFLAGS: LDFLAGS_CLI and LDFLAGS (or LDFLAGS_DAEMON, or some > > such). It's chump, but a few ms here and there, or a little more > > IO there eventually add up, especially in the arena of on > > connection times. > > Backend only forks(). I think you would be better off using > Makefile macros to _remove_ those two libraries. > > I see this: > > $(filter crypt.o getaddrinfo.o inet_aton.o snprintf.o strerror.o path.o > thread.o, $(LIBOBJS)) > > Seems you need the reverse.
Ah, well, if it fork()'s, then I don't really care. The best remaining argument for this would be to reduce the total size of a machine's VM page table size and possibly the expense of switching contexts between procs, but that's a pretty weak argument for only .5M of shared RAM. For some reason I thought it exec()'ed a child with the args necessary for it to read in a postgresql.conf. Looks like the comment in backend/storage/ipc/ipci.c is out of date then: * AttachSharedMemoryAndSemaphores * Attaches to the existing shared resources when exec()'d off * by the postmaster. -sc -- Sean Chittenden ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings