On Dec 15, 2007, at 4:24 PM, Alex Mizrahi wrote:
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:
This may be a silly question, but can't you just flush the cache on
delete so it has to fetch the window again?
(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
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
