[elephant-devel] Re: traversing btree using multiple indices

[Alex Mizrahi]

 IE> The string tuple-sorting hack makes me cringe.

yep, this looks weird. but i mostly have id-and-time situation, and it works 
fine for it.

 IE>   I know that I could make BDB and the lisp side sort lists based on
 IE> their constituents pretty easily if you felt we could make the same
 IE> hack work in postmodern.

i think hack for postmodern would be quite different one -- rather than 
messing with custom sorter, we can make multiple columns in our btree 
tables --
i.e. it was (qi, value), and we make it (qi1, qi2, value). it requires 
considerable amount of work to adapt queries to work with this,
but it's quite useful feature to have.

 IE> Maybe we could create a special tuple object for sorting aggregates so
 IE> we didn't break the 'cannot sort on non-primitives' guarantee today.

yep, special tuple type makes sense for postmodern, since it creates table 
according to types of first pair inserted.

 IE> As for Sean's request about doing an efficient intersection, as Alex
 IE> was explaining there are only two ways to do this efficiently:

no, these are two ways to do it inefficiently, there is only one way to do 
it efficiently -- via combined index :)

 IE> However, premature optimization often causes more trouble than it's 
worth.

yep, especially since it's quite easy to optimize it (addind indices etc) 
when it becomes slow.

 IE> The new unstable branch removes the MOP overhead so if your set sizes
 IE> are in the low 10's of thousands this should take less than a second.

if it is slow or not depends on a use case -- one thing is interactive 
application where queries are made in response to user action and few 
seconds of delay are OK.
another thing is a web site, where one slow query affects all users using 
this web site concurrently.