Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. If the existing secondary key equals to the new secondary key, it is a NO OP.
  2. If a previous secondary key exists, it deletes the existing secondary key-primary key pair from the secondary index.
  3. If a new secondary key exists, it inserts the new secondary key-primary key pair from the secondary index.

    Example:
    data type: [int(pk),int].
    existing data:
    single record {1,5}

    a) upsert {1,5}
    In this case, the secondary index upsert the old secondary key == the new secondary key. Hence, it will be no op.
    b) upsert{1,2}
    In this case, the secondary keys are not equal. Hence, we check:
    (previous value exists(not null) which was {5,1}, so we delete it)
    (new value is {2,1} so we insert it).
    c) upsert {2,2}
    In this case, there is no old value, we will only insert the key {2,2} in secondary index.
  • The Upsert commit operator commits the transaction creating Upsert logs if an old value was deleted in the transaction and an Insert log otherwise.
  • When an Upsert log is flushed to disk, the operation counter is decremented twice since it performed two operations.

- Special considerations for Filters

If the dataset is filtered, some extra operations must be done specifically for upsert in the case that a record is being replaced with a new value. After the new record is inserted, the filter will be updated by the index itself with the filter value of that record. However the record being upserted may exist in an immutable component, whereas the new record will be in a memory component. Thus searches that use the old filter value may not go into the new component that contains the new values we have inserted, but only see the old value. Thus we must update the filter separately, after inserting the new one into the index, with the filter value of the previously found tuple. This way searches with the old filter value will see the new record value.