[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: proxy-cache

Remco Post wrote:

Pierangelo Masarati wrote:

There were no changes between 2.2.15 and 2.2.17; there are lots of changes
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, but I
never used very large databases. You can revert to the old behavior by
recompiling back-sql (actually, all you need to recompile is schema-map.c)
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 better



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.

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 any drawback.

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