[elephant-devel] Re: Some performance optimizations

[Alex Mizrahi]

 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.