[elephant-devel] map-index

[Alex Mizrahi]

hello

i'm now trying to improve implementation of cursor in postmodern backend.
it would be nice to optimize it for usage patterns of map-index, but 
map-index implementation frightens me: is there a reason for such 
complexity?

for example, just to enumarate index with two values it does calls like 
this:

(cursor-pfirst c) => 1
(cursor-pnext-dup c) => nil
(cursor-pset c 1)
(cursor-pnext-nodup c) => 2
(cursor-pnext-dup c) => nil
(cursor-pset c 2)
(cursor-pnext-nodup c) => nil

while in my opinion it would be enough to do this:

(cursor-pfirst c) => 1
(cursor-pnext c) => 2
(cursor-pnext c) => nil

even if cursor is aware of such behaviour and caches cursor-pset, it's still 
a waste of CPU cycles to do 3 times more calls and demand cursor to do 
dup/nodup checks.

next, if we have query by value, i think optimal sequence would be:

(cursor-pset c value) => 1
(cursor-pnext-dup c) => 2
(cursor-pnext-dup c) => 3
(cursor-pnext-dup c) => nil
...

that is, if cursor has enough logic to enumerate duplicates  (all values for 
given key), why not use it?
however when cursor-pnext-dup returns NIL, that means there's no more values 
with such key, elephant does once more (cursor-pset c value), and tries 
(cursor-pnext-nodup c), and then uses lisp-compare<= on returned value.

this was actually a reason for error Henrik have reported.
db-postmodern's ordering of keys differs from lisp-compare ordering (and in 
some cases it's just random). normally that should break only range queries.
but with aforementioned (overly-general?) map-index logic it breaks even 
simple get-instances-by-value calls, which is not good.

so, am i missing something, or really it would be better to refactor 
map-index?

if it would be calling only what's needed, but won't do cursor-pset "for 
generality" i can skip cursor-pset optimization -- i don't think anybody in 
real code working with cursors will repeatadly call cursor-pset without a 
reason.

with best regards, Alex 'killer_storm' Mizrahi.