That sounds like we do a lot of work to handle edge cases where it might not exist, at the expense of the normal case where it’s unamibiguous with the minimal data we could read. This could be optimised a great deal.
At least this is another thing we can easily improve with accord, since we can do replica level filtering so we can decide we have enough information and stop. > On 4 Jan 2025, at 05:24, J. D. Jordan <jeremiah.jor...@gmail.com> wrote: > > > SGTM. > > Also I think you do actually need to resolve the full partition for the > second one. You have to merge tombstones+columns from all replicas to decide > if the partition exists. It’s the same reason we have to read all row data > for a given row during regular reads to decide if the row exists. Even if > only one column is selected. > >>> On Jan 3, 2025, at 3:23 PM, David Capwell <dcapw...@apple.com> wrote: >>> >> As part of the Accord work we have been extending the harry models to >> support even more of the CQL domain and added more test coverage for >> different features; in doing so it found the following query is currently >> blocked >> >> — delete partition if static column is in a given state >> — confirmed that this does not lead to a full partition read in CAS, but >> only a static row read >> — We already support delete static column if static condition, which has the >> same read cost as delete partition if static condition >> DELETE >> FROM tbl >> WHERE pk = ? — pk is the only partition key, but there are clustering keys >> IF s0 = ? — s0 is static >> >> >> I took a stab at fixing this in >> https://issues.apache.org/jira/browse/CASSANDRA-20163 and speaking with >> Benedict it was deemed that we should bring this up to the ML for visibility. >> >> In 2.0.11/2.1.1 https://issues.apache.org/jira/browse/CASSANDRA-6430 was >> added which blocked this type of query. The main argument seems to be that >> some deletes are confusing so should block instead ((assuming static >> columns) delete regular column if the partition exists, delete if regular >> column matches condition, etc.), but I argue that the case above isn’t >> ambiguous as we are working with static columns, so implicitly we are >> working at the partition level; aka partition delete. >> >> Are people ok with this change? >> >> Another case that was found in testing was >> >> — delete partition if exists >> DELETE >> FROM tbl >> WHERE pk = ? — pk is the only partition key, but there are clustering keys >> IF EXISTS >> >> I confirmed that this case does a full partition read (even though it >> doesn’t need to, just needs liveness info), my patch keeps this blocked not >> because its ambiguous, but because it has an unbounded cost (if you do this >> to a 1tb partition, you read 1tb… or try to at least…). We could fix this >> but felt was out of scope of the work above. >> >> Thanks!
