AM> of course this new implementation doesn't solve all issues, but at AM> least cursor operations now do not slow down with table growth, to the AM> extent PostgreSQL does not.
also important note about cursor implementation, which makes it somewhat different from bdb cursor behaviour, -- it fetches batches of k/v pairs at once, to mitigate communication overhead (default batch size is 10). so, even if you delete values from btree, you have can still get them from cache of cursor. it can read from cache only on next/prev operations, operations like set fetch fresh data from database. effect of caching mostly will go away if you bind *cursor-window-size* to 1. also, duplicated cursor does not inherit cache, so cursor-duplicate can be used to flush caches. AM> won't it be better to define something like: AM> (defun remove-current-kv () AM> (multiple-value-bind (f k v) AM> (when f AM> (cursor-current *current-cursor*) AM> (cursor-delete *current-cursor*) AM> (cursor-set-range *current-cursor* k)))) obviously that won't work.. with db-postmodern we can use the fact that cursor works correctly regardless of if current key/value is still in db. so we can do: (defun remove-current-kv () (cursor-delete (cursor-duplicate *current-cursor*))) i don't know if it works in other backends.. or maybe they do not make cursor uninitialized on delete and problem is non-existent? without this property, i'm afraid it's not possible to implement remove-current-kv without using details of current iteration operation. _______________________________________________ elephant-devel site list elephant-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/elephant-devel
