[pybsddb] Making calls to keys() more efficient (or, how to do inequality gets on keys?)

[Francisco Olarte (M)]

Unfortunately, the db in question is not a btree, so I couldn't use the
cursor idea.

>
> I wound up using a more frequent purge interval in the short-term, which
> gave me enough time to put the timestamp in the value, where I could use a
> secondary index to get the range of expired keys I needed.
>
>  If you are actually using so many keys, you can use range key request in
>> Berkeley DB. I am not sure we support it yet in pybsddb. I can not check
>> it now. But if not, and you need it, just ask and I would add it to the
>> new pybsddb version.
>>
>
> Is range key request limited to btrees? If not, then I'd vote for it to be
> included in pybsddb as well.
>

Probably everybody supposed a btree because the only reason we could think
off for putting a timestamp at the front of the key was to use an ordered
map, and the btree is the ordered map implementation in BDB. Range key
request is normally limited to ordered data structures. If you are using
hashes you don't have an order relation defined ( btrees normally need
less-than defined on the keys, you can derive equal from it ( a equals b is
the same as not (a less than b or b less than a) , hashes need a hash
function plus an equals function, and they are unordered, in fact traversing
ordering usually changes as the hash table is updated and needs to be
rehashed ).

F.O.S.




> _______________________________________________
> pybsddb mailing list
> pybsddb at jcea.es
> https://mailman.jcea.es:28443/listinfo/pybsddb
> http://www.jcea.es/programacion/pybsddb.htm
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.jcea.es/pipermail/pybsddb/attachments/20100618/567e78eb/attachment.htm>