From reading the WT disagg code, I was trying to understand why we need to perform __clayered_lookup and __clayered_put together inside our CRUD operations.

• __clayered_put performs inserts and updates on specific tables depending on the leader/follower mode places.
• __clayered_lookup abstracts the follower/leader mode and used for general-purpose lookups.

Here is an example from update:

    if (!F_ISSET(cursor, WT_CURSTD_OVERWRITE)) {
        WT_ERR(__clayered_lookup(session, clayered, &value));
        /*
         * Copy the key out, since the insert resets non-primary chunk cursors which our lookup may
         * have landed on.
         */
        WT_ERR(__cursor_needkey(cursor));
    }
    WT_ERR(__clayered_deleted_encode(session, &cursor->value, &value, &buf));
    WT_ERR(__clayered_put(session, clayered, &cursor->key, &value, true, false));

For an update() operation and overwite not being set, we want to check if the key exists. If it does, we want to update and if it doesn't we early exit from here. In disaggregate land we need to perform a cursor->search(), copy cursor() and then perform the update(). However the update() operation already traverses the tree and performs the update().

We should investigate on why we need both, and look into the upstream performance impacts this may have in disaggregate MongoDB