cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Josh McKenzie (Jira)" <>
Subject [jira] [Updated] (CASSANDRA-16675) Preserve Query Performance with ClusteringIndexNamesFilter After Running DROP COMPACT STORAGE
Date Tue, 20 Jul 2021 20:04:00 GMT


Josh McKenzie updated CASSANDRA-16675:
    Reviewers: Josh McKenzie

> Preserve Query Performance with ClusteringIndexNamesFilter After Running DROP COMPACT
> ---------------------------------------------------------------------------------------------
>                 Key: CASSANDRA-16675
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Legacy/Local Write-Read Paths
>            Reporter: Caleb Rackliffe
>            Assignee: Caleb Rackliffe
>            Priority: Normal
>             Fix For: 4.0.x
> Before the completion of CASSANDRA-16226, upgrading a cluster from 2.1 to 3.0 with compact
tables could cause a significant regression in the latency of reads using ClusteringIndexNamesFilter.
The details are described in that Jira, but in short, 3.0+ did not skip SSTables it should
have during reads, because it thought (wrongly) there might be primary key liveness information
in SSTables for compact tables.
> CASSANDRA-16226 addressed this behavior for still-compact tables, and also maintained
it after DROP COMPACT STORAGE was run. However, it also allowed tables that were never compact
to drop rows from query results if they contained no live non-key columns, which is only a
normal behavior for compact tables. This is addressed in CASSANDRA-16671 by reverting the
bits of the logic from CASSANDRA-16226 that deal with formerly compact tables where DROP COMPACT
STORAGE has been run, in the interest of unblocking the 4.0 release and making sure strictly
compact and strictly non-compact tables are queried properly and construct properly formed
> This goal of this issue is to safely restore the performance of formerly compact tables,
which necessarily contain ambiguous primary key liveness info. Roughly, the idea is that we
record in a system table (and pull into TableMetadata) the time when DROP COMPACT STORAGE
is executed. If a time exists for a table, we can treat it as being formerly compact, and
ignore primary key liveness info for determining row completeness in SinglePartitionReadCommand#isComplete().
Otherwise, the normal rules for never-compact tables will apply, avoiding any regression in
the scenario described by CASSANDRA-16671.
> This would obviously not be helpful in the case where a user has already dropped compact
storage, but it may logically be the best we can do, given we cannot correctly reconstruct
liveness info for SSTables created while a table was compact (i.e. there is no way to tell
INSERT and UPDATE apart for those). Especially if CASSANDRA-16671 moves in the direction of
disabling DROP COMPACT STORAGE by default, I would also propose that we do this only for 4.0+.

This message was sent by Atlassian Jira

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message