On Mon, May 09, 2005 at 05:28:05PM +0200, Thomas Guettler wrote:
> > > Since btrees and btree ranges don't know their size, you need to do
> > > something like this:
> > > - do range searches at the end
> > > - if index "foo" is used, use it first, ...
> >
> > Hmmm. Can you elaborate on this? I don't quite grasp what you mean.
> 
> If you want the intersection (AND) of some sets, you can increase the speed
> if you take the the smallest set and check for each entry if it is a member 
> of 
> the other sets. If you do take the large set first, you need to do more 
> checks for membership.
> 
> The applhe large set first, you need to do more 
> checks for membership.
> 
> The application developer might know that a search in index "foo" results in 
> small results. That's what I meant with "if index 'foo' is used, use it 
> first".

Ah, yes, this makes lots of sense. Hardcoding these heuristics isn't
very nice, though -- at least I don't know how to do it beyond using a
learning query optimizer, or telling the user to reorder his query: for
instance, in IC, it is faster to query through a small catalog and AND
that with a large catalog than the reverse. Having the user alter the
order of the query is a hack but it allows for situation-specific
optimization, which in many contexts is useful.

We do a little trick that avoids even touching the larger catalog (and
the largish sets that are stored in their keys) when doing ANDed joins:
if the number of items in the smaller catalog is below a certain magic
number, we synthesize a temporary index with just those values, querying
through there. This surprisingly gives great results.

However, then I question the general validity of the phrase:

> > > - do range searches at the end

Because in the case of our [business-oriented] applications,
double-bounded range searches (A < x < B) are among the fastest, thanks
to BTree index operations.

--
Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 3376 0125
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/

ZODB-Dev mailing list  -  ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev

Reply via email to