Re: proxy-cache

[Pierangelo Masarati <ando@sys-net.it>]

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
> > schema-map.c).
> >
> > 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
> > way...
> >
> > p.
>
>
> Hi,
>
> 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 :).

p.




   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497