> > % 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