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. _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel