On Tue, Nov 17, 2009 at 08:38:00PM -0500, Simo Sorce wrote:
I've been thinking about optimizing group enumerations for a
they were way too slow for my taste.
I did that by relying on the way we store users in the database and by
parsing the member attribute of the groups counting on the fact we build
the user dn as name=<username>,cn=users,....
We already rely on this in sysdb_search_user_by_name_send() so I think
it's ok to do it here, too.
This patch does indeed help a lot as the speedup with a large database
is huge, on my machine the reduction is of at least 1 order of magnitude
(from 2.5 seconds to 0.15 seconds)
With this patch we do one search only ( therefore O(n) ) instead of a
series of searches ( O(n^2) ).
I also removed a lot of code, which is usually also a good thing.
You don't like the recommendation in
, don't you?
The downside is that I don't have a user entry to test for uid range, so
I can't exclude users based on that.
However I think we should move both name filtering and range filtering
in the backend code and enforce them once at store time instead of
testing and enforcing them again and again and again each time we query
If the range or list of filtered name changes we should catch that by
simply filtering the database when the settings change and at startup.
Comments are welcome.
I agree, you have already provided a patch for this and we should
continue discussing the details in that thread.