Right now they're 32 bits by convention, but I'd like them to be 64- bits on a 64-bit machine eventually so far I don't think we're in danger of blowing out 32 bits of oids - you can compact OID values by doing a migration. Actually it wouldn't be hard to replace this with a 'find next unused oid' given that we have an oid table and the beginnings of a GC algorithm now.
Ian On Jan 14, 2009, at 3:07 PM, Yarek Kowalik wrote: > Out of curiosity, the OIDs in elephant are they 32 bit integers or > 64? I'm running on Ubuntu-64/SBCL-64. > > I'm thinking that my 'query' slot vale would be generated something > like this (for 32 bit values): > > (format t "~8,0X ~8,0X" slot-a-val slot-b-val) > > Yarek > > On Tue, Jan 13, 2009 at 5:51 PM, Robert Synnott <rsynn...@gmail.com> > wrote: > I don't believe the Postmodern backend, at least, allows search by > conses. > > If you want sensible (ordered) results with a and b if a and/or b are > integers, by the way, you should zero-pad them; otherwise, say, '1 2' > comes after '1 12', which is probably not what you want > Rob > > 2009/1/14 Yarek Kowalik <yarek.kowa...@gmail.com>: > > When serializing tuples, is the string representation best: You > suggest > > using (format t "~A ~A" a b) - is that efficient enough? what > about doing > > (cons a b) = is there a way to index and search for conses? Any > other ideas? > > > > Yarek > > > > On Tue, Jan 6, 2009 at 5:17 AM, Alex Mizrahi > <killerst...@newmail.ru> wrote: > >> > >> YK> Is this a reasonable way of finding an object of type > >> YK> 'my-class that matches on values val-a and val-b for slots a > and b? > >> > >> yep, it is reasonable if you have relatively low number of objects > >> in returned by (get-instances-by-value 'my-class 'slot-b val-b) > query. > >> if number of objects is significant and you get a slowdown because > >> of this, you might want to optimize this. a trivial thing is to > try it > >> symmertrically with slot-a -- whatever returns less objects is > better. > >> less trivial optimizations would be to work on lower-level -- via > >> map-inverted-index (to avoid allocating whole list but instead test > >> objects > >> one by one) or even cursor API (this way you can retrieve oids > rather > >> than objects, which should be faster, and also iterating both > indices at > >> once might be a significant benefit if values are not uniformly > >> distributed). > >> > >> but the most optimal way doing this in case of high number of > objects > >> in both slot-a and slot-b queries would be building and using > multi-column > >> index. unfortunately, Elephant does not help you with it -- > either you'll > >> have > >> to serialize slot tuples into a string (e.g (format nil "~a_~a" > slot-a > >> slot-b)), > >> or reorganize your data to use a custom index structure (like > btree of > >> btrees). > >> > >> there are also backend-specific considerations. for postmodern > >> > >> (intersection (get-instances-by-value 'my-class 'slot-b val-b) > >> (get-instances-by-value 'my-class 'slot-a val- > a)) > >> > >> would be much faster then testing objects one by one, for BDB -- > i doubt > >> so. > >> > >> LP> Use MAP-CLASS, this will considerably speed up the query. > >> > >> how is that? using at least one index is much better than using > no index > >> at > >> all. > >> > >> > >> > >> > >> _______________________________________________ > >> elephant-devel site list > >> elephant-devel@common-lisp.net > >> http://common-lisp.net/mailman/listinfo/elephant-devel > > > > > > _______________________________________________ > > elephant-devel site list > > elephant-devel@common-lisp.net > > http://common-lisp.net/mailman/listinfo/elephant-devel > > > > > > -- > Robert Synnott > http://myblog.rsynnott.com > MSN: rsynn...@gmail.com > Jabber: rsynn...@gmail.com > > _______________________________________________ > elephant-devel site list > elephant-devel@common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel > > _______________________________________________ > elephant-devel site list > elephant-devel@common-lisp.net > http://common-lisp.net/mailman/listinfo/elephant-devel _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
