[elephant-devel] Re: Some performance optimizations

[Ian Eslick]

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 at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel