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
