Hi Rich,
for DSEE we always had the discussion what is an unindexed search, or
when should notes=U be logged. We did log notes=U only if there was no
finite idlist and a full db scan had to be done. The finite idlist could
be that in an AND one of the filtercomponents was indexed, or in an
unindexed filter the idlist got finit by scoping (parentid, ancestorid).
We then had the request to differentiate if it was unindexed before or
after applying the system indexes.
Looks like RFDS reports notes=U if any filtercomponent touched is unindexed-
Ludwig
On 01/18/2013 04:53 PM, Rich Megginson wrote:
On 01/18/2013 08:29 AM, Picture Book wrote:
filter="(&(AllowAccess=Y)(uid=bill))"
AllowAccess is unindexed attribute
uid is indexed attribute
access log search result: notes=U
I imagine that directory server will do an indexed search by
uid=bill, get the entry and then verify if AllowAccess=Y. To me this
kind of search is indexed search.
example:
[18/Jan/2013:10:17:24 -0500] conn=124757 op=1 SRCH
base="ou=people,dc=?" scope=1 filter="(&(AllowAccess=Y)(uid=bill))"
attrs=ALL
[18/Jan/2013:10:17:24 -0500] conn=124757 op=1 RESULT err=0 tag=101
nentries=1 etime=0 notes=U
etime=0 confirms that this search is fast.
You might imagine that, but that's not how the server works. It
parses the filter, sees that AllowAccess is unindexed, and uses an
unindexed search.
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
--
389 users mailing list
389-users@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/389-users
