[Date Prev][Date Next]
Remco Post wrote:
I think I've spotted the problem. For some reason I can't remember (nor
explain at the moment) I removed that part of the condition for
ldap_entry_objclasses. I'm considering the opportunity to put it back,
since it largely reduces the amount of candidates selected when
filtering for an "auxiliary" objectClass and, at the moment, I don't see
Pierangelo Masarati wrote:
There were no changes between 2.2.15 and 2.2.17; there are lots of
between 2.2.17 and HEAD; at a first glance there's not much that should
impact performances. There's a small issue, I had to change the way
schema mapping is looked up; at some point it was done by comparing
pointers, but that made tests not portable because attribute ordering in
the results was machine or even run-time dependent; so I made it default
to strcmp based. I haven't noticed significant performance impact,
never used very large databases. You can revert to the old behavior by
recompiling back-sql (actually, all you need to recompile is
with -DBACKSQL_USE_PTR_CMP (see the comment at the beginning of
This may (and will) cause sql-test* fail because the results are not
ordered as in the reference.
Anybody please holler if you find a better way to sort results in a
I've done a bit of digging and it seems the difference is in the way
the candidate list is constructed. The new query is much much slower
than the new one (by a large amount), I guess that the (maybe overly
redundant) phrase 'ldap_entries.id=ldap_entry_objclasses.entry_id and'
helps the query optimizer in postgres a lot....
If it doesn't make any differnce to you, I guess I liked the
performance of the old query a lot better.
BTW, I note that in both queies there's a redundant condition (i.e. an
implicit "ldap_entries.oc_map_id=?" with value '3' followed by an
explicit explicit "ldap_entries.oc_map_id=3", which should be
supposedly detected and eliminated by the RDBMS; I'll see if I can
safely remove it).
I note that there are other issues resulting from my recent changes;
one for all is that to allow the broadest possibility to exploit
attribute (and objectClass) inheritance in filters, some queries may
result in candidating the whole database. There should be some
possibility to narrow down the amount of candidates, even at some
acceptable computational cost in terms of navigating the inheritance
tree of slapd's schema, which should be reasonable compared to the
overhead of generating and (unsuccessfully) testing all the entries :).
SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497