Someday it would be nice to have timestamps under the hood (and be able
to do MVCC :-))....
On 8/1/25 3:36 PM, Taewoo Kim wrote:
Thanks Mike. I see what you mean. Yes, there's no guarantee that a
later-fetched entry is the latest one unless we have the timestamp (or a
counter) attached. I agree with the semantics proposed. Unless we can
extend the functionality of the secondary index fetch, it seems not easily
doable to return the latest only.
Best,
Taewoo
On Fri, Aug 1, 2025 at 3:21 PM Mike Carey<dtab...@gmail.com> wrote:
Clearer, but depending on the nature of a conflicting update, couldn't
the second one encountered be the older one? (E.g., if something moves
lower in the order that the index is based on, e.g., if a price is
reduced and the secondary index is on price?) I'm not sure there's an
update-timestamp-free way of knowing which one is newer, in terms of its
presence in the index...?
On 8/1/25 2:34 PM, Taewoo Kim wrote:
Sorry, I was not clear. :-) When extracting <SK, PK>, we add a
monotonically increasing counter (doesn't have to be a timestamp) to the
<SK, PK> pair so that <SK, PK, counter> if it's an index-only plan and
use
it. This counter can be only added when instant Try-lock on PK fails to
differentiate.
On Fri, Aug 1, 2025 at 2:11 PM Mike Carey<dtab...@gmail.com> wrote:
The entries don't necessarily have a timestamp - wish they did! (Just
secondary and primary keys if I remember right.)
On 8/1/25 12:52 PM, Taewoo Kim wrote:
PS. What if we add the timestamp to the fetched entries so that we
always
pick the latest one when sorting PK?
Best,
Taewoo
On Fri, Aug 1, 2025 at 12:07 Taewoo Kim<wangs...@gmail.com> wrote:
+1
Best,
Taewoo
On Fri, Aug 1, 2025 at 11:43 Mike Carey<dtab...@gmail.com> wrote:
BTW +1 from me too on the proposal
On 8/1/25 11:19 AM, Ian Maxon wrote:
+1, this will be a great improvement.
On Fri, Aug 1, 2025 at 9:59 AM Shahrzad Haji Amin Shirazi
<shahrzad.hajiaminshir...@email.ucr.edu> wrote:
Hi All,
Initiating a discussion to propose the change in index-only
query plans in AsterixDB.
*Feature:*: Simplifying the index-only query plans
*Details:* In the current version of AsterixDB, index-only
query plans are complex and challenging to maintain.
They involve a complex query plan that enforces strict consistency
guarantees. The proposed feature will simplify these plans by
relaxing those guarantees, which would significantly enhance
maintainability and usability.
*Changeset*:https://asterix-gerrit.ics.uci.edu/c/asterixdb/+/17729
*APE*:
https://cwiki.apache.org/confluence/display/ASTERIXDB/APE+24%3A+Index-only+plans
Sincerely,
Shahrzad
