unnecessary attr. lookups?

[Brian Jones <jonesy@CS.Princeton.EDU>]

Hi all. 

I'm looking at my logs (loglevel=256), and I'm running a bunch of operations
to see basically how different things are working, and I found something
that seems a little unusual.

On a machine that is configured to use nss_ldap for
passwd/shadow/groups/netgroup/hosts, I ran "ls -l" in a directory where
there were about 20 directories, each with different user:group ownerships.
Here's the log output for the generation of ONE line of "ls -l" output:

~~~~~~~~~~~~~~ snip ~~~~~~~~~~~~~~~~~~

May  9 15:24:58 pengo slapd[27864]: conn=38 op=4 SRCH
base="ou=People,dc=my,dc=domain,dc=org" scope=1
filter="(&(objectClass=posixAccount)(uidNumber=1722))"

May  9 15:24:58 pengo slapd[27864]: conn=38 op=4 SRCH attr=uid userPassword
uidNumber gidNumber cn homeDirectory loginShell gecos description
objectClass 

May  9 15:24:58 pengo slapd[27864]: conn=38 op=4 SEARCH RESULT tag=101 err=0
nentries=1 text= 

~~~~~~~~~~~~~~~ snip ~~~~~~~~~~~~~~~~~~

I understand that the local system has to map uid#/gid# to names, but why
does it need to *also* get all of those other attributes (homeDirectory,
loginShell, etc) for every uidNumber it looks up?  It would seem that the
simple uidNumber=>uid mapping would suffice...? I've probably missed some
doc somewhere that points this all out, so as usual, pointers to it are
welcome. What I really want to know is if it's possible to slim down the
number of attributes being requested here, as I am anticipating this server
being queried by several *nix boxen with (consistently) ~50 active users
each, and I'm a little concerned about the resulting performance on the LDAP
server (and, thus, perceived performance degradation to the users).

brian.