asterixdb-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Taewoo Kim (Code Review)" <>
Subject Change in asterixdb[master]: Index-Only Plan Patch Set 4: modifies SearchOpCallBack
Date Tue, 28 Mar 2017 21:18:57 GMT
Taewoo Kim has posted comments on this change.

Change subject: Index-Only Plan Patch Set 4: modifies SearchOpCallBack

Patch Set 5:

(1 comment)

Every cursor implementation will be somewhat difficult. But, currently, we don't correctly
handle it. When Young-Seok and I talked about this issue, we found it. The current implementation
of search cursor is not correct for this matter. 

For your first and third bullet, we want to use the tryLock in proceed() as a real function.
It may return true or false. If it returns true, then it's OK. But, an anti-matter tuple can
be returned. Since this tuple should not be returned, the effect of the proceed() needs to
be reversed. Any action on the proceed (lock) needs to be reversed (unlock). Reconcile will
work when proceed() returns false. In that case, lock() will be used instead of tryLock().

For your second bullet, yes, proceed() always succeeds. It's not blocked. But, the effect
of that might be canceled as the above case.
File hyracks-fullstack/hyracks/hyracks-storage-am-lsm-invertedindex/src/main/java/org/apache/hyracks/storage/am/lsm/invertedindex/impls/

PS5, Line 181: ;
> Calling those in hasNext() looks problematic since you don't know whether/w
Actually, that's the way it works now. For example, for LSMBTree, hasNext() does everything
to make sure a valid tuple is in its head of the priority queue. Then, next() just gets it.

To view, visit
To unsubscribe, visit

Gerrit-MessageType: comment
Gerrit-Change-Id: I16992b3bdc1bfc739417d11366d6bafc59294a0b
Gerrit-PatchSet: 5
Gerrit-Project: asterixdb
Gerrit-Branch: master
Gerrit-Owner: Taewoo Kim <>
Gerrit-Reviewer: Jenkins <>
Gerrit-Reviewer: Taewoo Kim <>
Gerrit-Reviewer: Yingyi Bu <>
Gerrit-HasComments: Yes

View raw message