Re: Obfuscation of passwords in audit loging, in or not in 4.0?

I am on the side of "this sounds like a really bad bug" for the audit pieces, maybe less so than FQL. Anyone using audit for real probably has meaningful audit requirements, which means they're in an industry where they get audited for security, which means logging passwords is a big deal. On T

Re: Additions to Cassandra ecosystem page?

This would be my preference. On Wed, Jun 23, 2021 at 2:22 PM Ben Bromhead wrote: > I'm also comfortable with a strict approach where we just list actual > Apache Cassandra offerings, that also provides good solid clarity to users. > > On Thu, Jun 24, 2021 at 3:06 AM bened...@apache.org > wrote

Re: [VOTE] Release Apache Cassandra 4.0-rc2

+1 > On Jun 28, 2021, at 9:00 PM, Jeremy Hanna wrote: > > +1 (nb) nice to see all of the fixes and the use of newer TLS by default and > obfuscation of passwords in the audit log for the 4.0 release. > >> On Jun 29, 2021, at 6:01 AM, Jon Meredith wrote: >> >> +1 (nb) >> On Mon, Jun

Re: [VOTE] Release Apache Cassandra 4.0.0 (take2)

+1 On Tue, Jul 13, 2021 at 3:14 PM Mick Semb Wever wrote: > Proposing the test build of Cassandra 4.0.0 for release. > > sha1: 924bf92fab1820942137138c779004acaf834187 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.0-tentative > Maven Artifacts: > > https

Re: [DISCUSS] CEP-10: Cluster and Code Simulations

Same On Wed, Jul 14, 2021 at 9:16 AM Brandon Williams wrote: > I am +1 to both removal from the template and "we need this" > > On Wed, Jul 14, 2021 at 9:05 AM Joshua McKenzie > wrote: > > > > And I'm a +1 on the "I agree we need this". > >

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

There's a tactical issue, too, that virtual tables require native transport to be up before it's usable, so for things pre-startup (e.g. querying streaming state during bootstrap), so I don't think nodetool/jmx dies entirely ever (or, a non-client-facing-virtual-tables-only port has to be created,

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

On Thu, Jul 15, 2021 at 12:59 PM Brandon Williams wrote: > On Thu, Jul 15, 2021 at 8:59 AM Paulo Motta > wrote: > > > > Perhaps one approach to expose VirtualTables via nodetool without > requiring > > the user to provide CQL credentials would be to provide a generic > > StorageServiceMBean.quer

Re: [DISCUSS] Virtual Tables and the future of NodeTool/JMX

Agreed. Status quo is status quo. If someone wants to change status quo, CEP would be appreciated. Until CEP exists and is approved, work on patches in flight seems reasonable and valid. On Thu, Jul 15, 2021 at 12:38 PM J. D. Jordan wrote: > I see no problem with continuing to add JMX commands

Re: [VOTE] Release Apache Cassandra 4.0.0 (third time is the charm)

+1 > On Jul 22, 2021, at 3:41 PM, Brandon Williams > wrote: > > I am proposing the test build of Cassandra 4.0.0 for release. > > sha1: 902b4d31772eaa84f05ffdc1e4f4b7a66d5b17e6 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.0-tentative > Maven Artifac

Re: [DISCUSS] CASSANDRA-16840 - Close native transport port before hint transfer during decommission

The hint behavior aside, stopping native protocol once you begin a decom seems like something most people would benefit from, even if they dont realize that's what they want to happen. On Tue, Aug 10, 2021 at 12:53 PM Matt Fleming wrote: > Hi, > > With the way that hint transfer currently work

Re: [VOTE] CEP-11: Pluggable memtable implementations

+1 Sent from my iPhone > On Aug 19, 2021, at 9:19 AM, bened...@apache.org wrote: > > +1 > > From: Brandon Williams > Date: Thursday, 19 August 2021 at 17:16 > To: dev@cassandra.apache.org > Subject: Re: [VOTE] CEP-11: Pluggable memtable implementations > +1 > >> On Thu, Aug 19, 2021 at 11:1

Re: [DISCUSS] CEP 14: Paxos Improvements

> On Aug 22, 2021, at 7:25 PM, Miles Garnsey wrote: > >  >> >> The problem is that today there’s no way to reliably exclude the new DC from >> serving reads, that I know of? If you can, then yes you would only need to >> ensure repair were run prior to activating reads from this DC. > > W

Re: [VOTE] CEP-14: Paxos Improvements

+1 > On Aug 27, 2021, at 1:00 PM, Scott Andreas wrote: > > +1 > >> On Aug 27, 2021, at 12:58 PM, Mick Semb Wever wrote: >> >>  >>> >>> >>> Proposal: >>> https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-14%3A+Paxos+Improvements >>> Discussion: >>> https://lists.apache.org/thread.h

Re: [VOTE] Release Apache Cassandra 4.0.1

+1 On Wed, Sep 1, 2021 at 4:54 AM Sam Tunnicliffe wrote: > Proposing the test build of Cassandra 4.0.1 for release. > > sha1: 6709111ed007a54b3e42884853f89cabd38e4316 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.0.1-tentative > Maven Artifacts: > https:/

Re: [VOTE] CEP-13: Denylisting partitions

+1 On Wed, Sep 8, 2021 at 9:31 AM Sumanth Pasupuleti < sumanth.pasupuleti...@gmail.com> wrote: > Hi everyone, > > I’m proposing this CEP for approval. > > Proposal: > > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-13%3A+Denylisting+partitions > Discussion: > > https://lists.apache.o

Re: Tradeoffs for Cassandra transaction management

I'll read more of this in a bit, I want to make sure I fully digest it before commenting on the rest, but this block here deserves a few words: On Sat, Oct 9, 2021 at 9:54 AM Jonathan Ellis wrote: > After putting the above together it seems to > me that the two main areas of tradeoff are, 1. Is

Re: Tradeoffs for Cassandra transaction management

Do I read this email as "Jonathan will vote against any improvement to transactions that doesn't guarantee local latencies and interactive SQL, even though no such proposal exists, thereby blocking any improvement over the current status quo?" On Thu, Oct 14, 2021 at 6:55 AM Jonathan Ellis wrot

Re: [VOTE] CEP-15: General Purpose Transactions

I support adopting this CEP, and the transaction semantics, and the incremental approach to developing transactions, so I'm +1 on all three I also think that it is preferrable that we get to a point where the -1 be withdrawn, because I think it's a bad precedent to force the PMC to try to navigate

Re: [DISCUSS] CEP-3: Guardrails

Without bike-shedding too much, guardrails would be great, building them into a more general purpose framework that limits various dangerous things would be fantastic. The CEP says that the guardrails should be distinct from the capability restrictions ( https://issues.apache.org/jira/browse/CASSAN

Re: [DISCUSS] Creating a new slack channel for newcomers

New developers or new users? I'd be afraid that a new developer-focused channel might not get many eyes (or, it'll get the same 600 eyes, and it'll have the same problem). On Mon, Nov 8, 2021 at 8:29 AM Benjamin Lerer wrote: > Hi everybody, > > Aleksei Zotov mentioned to me that it was a bit in

Re: [VOTE] CEP-17: SSTable format API

+1 On Mon, Nov 15, 2021 at 11:43 AM Branimir Lambov wrote: > Hi everyone, > > I would like to start a vote on this CEP. > > Proposal: > > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-17%3A+SSTable+format+API > > Discussion: > > https://lists.apache.org/thread.html/r636bebcab4e678db

Re: Resurrection of CASSANDRA-9633 - SSTable encryption

For better or worse, different threat models mean that it’s not strictly better to do FDE and some use cases definitely want this at the db layer instead of file system. > On Nov 19, 2021, at 12:54 PM, Joshua McKenzie wrote: > >  >> >> >> setting performance requirements on this regard

Re: Resurrection of CASSANDRA-9633 - SSTable encryption

> On Nov 19, 2021, at 2:53 PM, Joseph Lynch wrote: > >  >> >> For better or worse, different threat models mean that it’s not strictly >> better to do FDE and some use cases definitely want this at the db layer >> instead of file system. > > Do you mind elaborating which threat models? Th

Re: [DISCUSS] CEP-19: Trie memtable implementation

Sounds like a great addition Can you share some of the details around gc and latency improvements you’ve observed with the list? Any specific reason the confirmation is through schema vs yaml? Presumably it’s so a user can test per table, but this changes every host in a cluster, so the impac

Re: UDF future

+1 > On Jan 18, 2022, at 8:38 AM, Jonathan Ellis wrote: > >  > +1 > >> On Tue, Jan 18, 2022 at 10:34 AM C. Scott Andreas >> wrote: >> I also (+1nb) support a proposal to deprecate JavaScript UDFs; to offer an >> interface for those who would like to supply a UDF implementation; and to >>

Re: [VOTE] Release Apache Cassandra 4.0.2

+1 On Tue, Feb 8, 2022 at 3:37 PM Joshua McKenzie wrote: > I find myself agreeing with Jeremiah's sentiment here. > > For example, we're asking people that are on 4.0.1 to make the difficult > choice between accepting the risk of whatever prompts an urgent release vs. > accepting the risk of po

Re: [VOTE] Release Apache Cassandra 4.0.2

(This was a +1 on the release, to be clear, not a +1 on the sentiment below, which I appreciate but still believe we should proceed with the release) On Tue, Feb 8, 2022 at 3:44 PM Jeff Jirsa wrote: > +1 > > > On Tue, Feb 8, 2022 at 3:37 PM Joshua McKenzie > wrote: > >>

Re: [RELEASE] Apache Cassandra 4.0.2 released

Accidentally dropped dev@, so adding back in the dev list, with the hopes that someone on the dev list helps address this. On Fri, Feb 11, 2022 at 2:22 PM Jeff Jirsa wrote: > That looks like https://issues.apache.org/jira/browse/CASSANDRA-17132 + > https://github.com/apache/cassandra/

Re: [RELEASE] Apache Cassandra 4.0.2 released

We don't HAVE TO remove the Config.java entry - we can mark it as deprecated and ignored and remove it in a future version (and you could update Config.java to log a message about having a deprecated config option). It's a much better operator experience: log for a major version, then remove in the

Re: [DISCUSS] Hotfix release procedure

We've done concurrent releases without security before, and you follow much closer than others. I feel most people, if they saw all of the changes reverted and a release of a single fix, would either instantly know it's security (high confidence pointer to exactly which patch) OR assume someone bot

Re: Using labels on pull requests in GitHub

An easier fix here is just to put a close action into the commit message: Closes #nnn e.g. https://github.com/apache/cassandra/commit/ad249424814836bd00f47931258ad58bfefb24fd / https://github.com/apache/cassandra/pull/1046 On Wed, Mar 16, 2022 at 5:40 AM Josh McKenzie wrote: > I think the fact

Re: CEP-15 multi key transaction syntax

> On Jun 3, 2022, at 8:39 AM, Blake Eggleston wrote: > > Hi dev@, First, I’m ridiculously excited to see this. > > I’ve been working on a draft syntax for Accord transactions and wanted to > bring what I have to the dev list to solicit feedback and build consensus > before moving forwar

Re: CEP-15 multi key transaction syntax

And would you allow a transaction that had > 1 named select and no modification statements, but commit if 1=1 ? > On Jun 4, 2022, at 2:45 PM, Jeff Jirsa wrote: > >  > >> On Jun 3, 2022, at 8:39 AM, Blake Eggleston wrote: >> >> Hi dev@, > > Firs

Re: [DISCUSS] Deprecate and remove resumable bootstrap and decommission

The hypothetical concern described is around potential data resurrection - would you still use resumable bootstrap if you knew that data deleted during those STW pauses was improperly resurrected? On Wed, Aug 3, 2022 at 2:40 PM Bowen Song via dev wrote: > I have benefited from the resumable boot

Re: dtests to reproduce the schema disagreement

Which (of the many) schema disagreement issue(s)? On Mon, Aug 8, 2022 at 3:29 PM Cheng Wang via dev wrote: > Thank you for the reply, Brandon! It is helpful! > > I was thinking of creating a cluster with 2 nodes and having two > concurrent CREATE TABLE statements running. But the test will be

Re: dtests to reproduce the schema disagreement

ddress is when there are two CREATE TABLE > queries running on two coordinator nodes concurrently, it might end up with > 2 schema versions and they would never get resolved automatically because > table id is random TimeUUID. > > > > On Mon, Aug 8, 2022 at 3:54 PM Jeff

Re: dtests to reproduce the schema disagreement

Stop node 1 before you start node 2, essentially mocking a full network partition. On Tue, Aug 9, 2022 at 11:57 AM Cheng Wang via dev wrote: > Thank you, Aleksey, > Yes, I have tried this approach, the problem is there is a timing window > that node 1 runs the CREATE TABLE while node 2 is down

Re: [DISCUSS] CEP-20: Dynamic Data Masking

This type of feature is very useful, but it may be easier to analyze this proposal if it’s compared with other DDM implementations from other databases? Would it be reasonable to add a table to the proposal comparing syntax and output from eg Azure SQL vs Cassandra vs whatever ? > On Aug 19,

Re: [DISCUSS] CEP-21: Transactional Cluster Metadata

“ The proposed mechanism for dealing with both of these failure types is to enable a manual operator override mode. This would allow operators to inject metadata changes (potentially overriding the complete metadata state) directly on any and all nodes in a cluster. At the most extreme end of th

Re: CEP-15 multi key transaction syntax

I expect that a lot of use cases will update M and insert into N tables based on one condition, so if that's a problem with the grammar today, I think it'd probably be worth the time to sort that out? On Wed, Sep 21, 2022 at 12:42 PM David Capwell wrote: > Caleb is making great progress on thi

Re: [Discuss] CEP-24 Password validation and generation

I don't think logging which policy violation was triggered is that big of an ask? "Password changed for user X, complying with policies (reuse, complexity, entropy)" "ERROR: Password rejected due to policy violation (reuse)" "ERROR: Password rejected due to policy violation (complexity)" "ERROR: P

Re: Should we change 4.1 to G1 and offheap_objects ?

G1 you can argue for with the changes in the JDK, though it's MUCH less friendly to small heaps (e.g. probably our default simple user). Offheap memtables are different though. If someone wants to attest that offheap_objects get the same level of rigorous testing as the existing default, that'd b

Re: Should we change 4.1 to G1 and offheap_objects ?

I'll withdraw my comment about friendliness of g1 vs cms. I think it's too late to sneak it in, but wouldn't object formally. offheap_objects is way too late to change given we shipped the alpha in May and there are known, long lived bugs that multiple users have reported and wouldn't have been te

Re: Should we change 4.1 to G1 and offheap_objects ?

On Thu, Nov 17, 2022 at 12:47 PM J. D. Jordan wrote: > -1 on providing a bunch of choices and forcing users to pick one. We > should have a default and it should be “good enough” for most people. The > people who want to dig in and try other gc settings can still do it, and we > could provide the

Re: [DISCUSS] CEP-44: Kafka integration for Cassandra CDC using Sidecar

Transactional metadata and Accord should make it MUCH easier to do duplication avoiding CDC (and I was going to note that someone should ensure that the interfaces exposed to the public are stable enough not to change the published api once those exist)On Sep 29, 2024, at 7:04 PM, Patrick McFadin

Re: Status of CEP-1

> On Oct 1, 2024, at 7:26 PM, Josh McKenzie wrote: > >> However it is used by a number of other features as a dependency such as >> analytics, backup/restore, repair, metrics, and CDC > It seems like a natural pressure relief valve for moving operations out of a > core C* node that are well s

Re: [Discuss] Repair inside C*

> On Oct 28, 2024, at 9:52 PM, Alexander Dejanovski > wrote: > >  > >> If a repair session finishes gracefully, then this timeout is not >> applicable. Anyway, I do not have any strong opinion on the value. I am open >> to lowering it to 1h or something. > True, it will only delay killing

Re: Unexplained stuck memtable flush

> On Nov 5, 2024, at 4:12 AM, Bowen Song via user > wrote: > > Writes on this node starts to timeout and fail. But if left untouched, it's > only gonna get worse, and eventually lead to JVM OOM and crash. > > By inspecting the heap dump created at OOM, we can see that both of the > Memtable

Re: [DISCUSS] Secondary Indexes and Single-Partition Reads

> On Oct 1, 2024, at 10:28 AM, Caleb Rackliffe wrote: > > Hello fellow secondary index enjoyers! > > If you're familiar with index queries, you probably know that they are > treated as range reads no matter what. This is true even if the user query > restricts results to a single partition.

Re: Re-evaluate compaction defaults in 5.1/trunk

> On Dec 7, 2024, at 7:08 PM, Mick Semb Wever wrote: > > Chiming in with my two cents… > > >> When people have the luxury of working in environments where clusters are >> massively over provisioned, LCS as a default makes a lot of sense, because >> there's not much downside. The use cases

Re: Re-evaluate compaction defaults in 5.1/trunk

On 2024/12/09 17:33:09 Benedict wrote: > I think it would make sense to support overriding the default FP in the UCS > parameters, so we can treat it as a direct replacement. Desiree FP is > directly related to sstable overlaps after all. > > Can you think of any other usability gaps like t

Re: [DISCUSS] Experimental flagging (fork from Re-evaluate compaction defaults in 5.1/trunk)

> On Dec 9, 2024, at 10:52 AM, Jeremy Hanna wrote: > >  > > In the case of UCS, is it in a beta state until we resolve the discussions > around UX/documentation? From a functional and production usage perspective, > it has been the only compaction strategy available for users in DataStax'

Re: Re-evaluate compaction defaults in 5.1/trunk

People who know enough to read the docs to find those profiles know how to read the docs to choose the right compaction already. Beyond that, it just clutters up the grammar and metadata. The reality here is there’s no single compaction strategy that works for everyone, so unless there’s strong

Re: Re-evaluate compaction defaults in 5.1/trunk

On 2024/12/09 16:26:45 Benedict wrote: > I think it’s important to remember that UCS broadly speaking subsumes both LCS > and STCS, with various subtle but important refinements. So while it offers a > broader parameter space it might be best to conceive of it as a suite of > compaction strategi

Re: [DISCUSS] 5.1 should be 6.0

You’ve added a ton of API surface to transaction behavior and cluster management. The TCM may or may not be strictly breaking, but they’re fundamentally very very different, so even with semver as the only standard, I think you can justify a major. But also, let’s just acknowledge that marketin

Re: [DISCUSS] Tooling to repair MV through a Spark job

It feels uncomfortable asking users to rely on a third party that’s as heavy-weight as spark to use a built-in feature. Can we really not do this internally? I get that the obvious way with merkle trees is hard because the range fanout of the MV using a different partitioner, but have we tried

Re: Re-evaluate compaction defaults in 5.1/trunk

I’m probably closely aligned with Chris here, fwiw. - Jeff > On Dec 6, 2024, at 7:40 PM, Chris Lohfink wrote: > > While I am actually +1 on LCS being default as it handles more use cases well > compared to STCS. I am -1 on UCS being default anywhere currently, the UX is > horrible, documenta

Re: Re-evaluate compaction defaults in 5.1/trunk

And it works for that most of the time, so what’s the concern? “You lose throughput because iops / write amplification go up, so the perf of the default install goes down” ? (But the cost per byte goes way down, too)? > On Dec 6, 2024, at 8:01 PM, Brad wrote: > > > Could you elaborate what

Re: Status of CEP-1

t;>>>>>> can't use it for 6 months because you're using >>>> analytics lib >>>>>>>>> and >>>>>>>>>>>> the people >>>>>>>>>>>>>>>> that contribute to

Re: What branches should perf fixes be targeting

We expect users to treat patch and minor releases as low risk. Changing something deep in the storage engine to be 1% faster is not worth the risk, because most users will skip the type of qualification that finds those one in a billion regressions. Patch releases are for bug fixes not perf imp

Re: What branches should perf fixes be targeting

f the improvements are that minor.JordanOn Tue, Jan 21, 2025 at 1:57 PM Jeff Jirsa <jji...@gmail.com> wrote:We expect users to treat patch and minor releases as low risk. Changing something deep in the storage engine to be 1% faster is not worth the risk, because most users will skip

Re: [DISCUSS] Replacement of SSTable's partition cardinality implementation from stream-lib to Apache Datasketches

I’m going to type a lot of extra words mostly for people just barely familiar with this part of the codebase, because it may or may not be useful to passive observers (it wasn’t to me, so I’m mostly echo’ing the things I just went and learned this morning): The HLL cardinality is used for bas

Re: Per partition local ordering

Not Patrick, but: - would also love being closer to SQL - there’s no work on this specific grammar, yet - it would depend on a real query optimizer, which IS somewhat in flight (or at least a cost based optimizer was proposed) > On Apr 7, 2025, at 2:05 PM, Artem Golovko wrote: > > Hi Patrick,

Re: [DISCUSS] CEP-36: A Configurable ChannelProxy to alias external storage locations

> On Apr 11, 2025, at 1:15 PM, Jon Haddad wrote: > > > I also keep running up against my concern about treating object store as a > write back cache instead of write through. "Tiering" data off has real > consequences for the user, the big one being data loss, especially with > regards to

Re: CEP-15 Update

Having played with the branch and confirmed it’s relatively isolated, I would love to see it mergedOn Mar 6, 2025, at 8:44 PM, Benedict Elliott Smith wrote:Because we want to validate against the latest code in trunk, else we are validating stale behaviours. The cost of rebasing is high, so we do

Re: [DISCUSS] CEP-36: A Configurable ChannelProxy to alias external storage locations

Mounting an s3 bucket as a directory is an easy but poor implementation of object backed storage for databases Object storage is durable (most data loss is due to bugs not concurrent hardware failures), cheap (can 5-10x cheaper) and ubiquitous. A  huge number of modern systems are object-storage-on

Re: [DISCUSS] CEP-36: A Configurable ChannelProxy to alias external storage locations

;?  It is eventually using same thing, no?On Tue, Mar 4, 2025 at 12:47 PM Jeff Jirsa <jji...@gmail.com> wrote:Mounting an s3 bucket as a directory is an easy but poor implementation of object backed storage for databases Object storage is durable (most data loss is due to bugs not concurrent hardwa

Re: [DISCUSS] CEP-36: A Configurable ChannelProxy to alias external storage locations

driver"?  It is eventually using same thing, no?On Tue, Mar 4, 2025 at 12:47 PM Jeff Jirsa <jji...@gmail.com> wrote:Mounting an s3 bucket as a directory is an easy but poor implementation of object backed storage for databases Object storage is durable (most data loss is due to bugs not co

Re: Dropwizard/Codahale metrics deprecation in Cassandra server

I think widely accepted that otel in general has won this stage of observability, as most metrics systems allow it and most saas providers support it. So Jon’s point there is important. The promise of unifying logs/traces/metrics usually (aka wide events) is far more important in the tracing side o

Re: [DISCUSS] Virtualise system_schema (CASSANDRA-19129)

The schema has to be durable on disk for cold start You could put a virtual facade in front of it for drivers but you need a durable physical copy of that schema somewhere, right? > On Feb 20, 2025, at 3:57 PM, Bernardo Botella > wrote: > > Hi everyone! > > As part of Jira ticket (CASSANDR

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

> On May 9, 2025, at 12:59 PM, Ariel Weisberg wrote: > > > I am *big* fan of getting repair really working with MVs. It does seem > problematic that the number of merkle trees will be equal to the number of > ranges in the cluster and repair of MVs would become an all node operation. > How

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

Setting aside the paxos vs accord conversation (though admittedly my first question would have been “why not accord”), I’m curious from folks who have thought about this how you’re thinking about correctness of repairI ask because I have seen far more data resurrection cases than I have lost write

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

how much better it is to look something up in the MV vs > just looking at the base table or some non-materialized view of it. How > exactly are these MVs supposed to be used and what value do they provide? > > Jeff Jirsa wrote: >> There’s 2 things in this proposal that give me a lo

Re: Stricter repair time requirements necessary to prevent data resurrection than advised by docs

> On May 16, 2025, at 10:22 AM, Mike Sun wrote: > > The Cassandra docs > > advise: >> >> At a minimum, repair should be run often enough that the gc grace period >> never expires on unrepaired data. Otherwise, d

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

Isn’t the reality here is that repairing a single partition in the base table is potentially a full cluster-wide scan of the MV if you also want to detect rows in the MV that don’t exist in the base table (eg resurrection or a missed delete)There’s no getting around that. Keeping an extra index doe

<    1   2   3   4   5