> > % ldd `which postgres` > > /usr/local/bin/postgres: > > libintl.so.5 => /usr/local/lib/libintl.so.5 (0x282e6000) > > libz.so.2 => /lib/libz.so.2 (0x282ef000) > > libreadline.so.4 => /lib/libreadline.so.4 (0x282fd000) > > libcrypt.so.2 => /lib/libcrypt.so.2 (0x28325000) > > libm.so.2 => /lib/libm.so.2 (0x2833e000) > > libutil.so.3 => /lib/libutil.so.3 (0x28357000) > > libc.so.5 => /lib/libc.so.5 (0x28363000) > > libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x2843d000) > > libncurses.so.5 => /lib/libncurses.so.5 (0x2852c000) > > > > Is it really necessary for postgres to be linked with ncurses > > (288K) and readline (156K)? It's .5M, not the end of the world, > > but it seems excessive. I know the postmaster has a CLI > > interface, but does it really require ncurses or readline? -sc > > 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. -sc -- Sean Chittenden ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html