Re: Wild card search | Cassandra

For what it's worth, I'm not sure how active Mike will be on the project going forward. If there is some desire to push forward, I wouldn't assume he's actively working on it. On Wed, Apr 30, 2025 at 7:02 AM Rolo, Carlos via dev < dev@cassandra.apache.org> wrote: > That would be in the next relea

Re: [VOTE] Simplifying our release versioning process

+1 On Tue, Apr 22, 2025 at 8:37 AM Ekaterina Dimitrova wrote: > +1 > > I also remember we agreed on Discuss thread for removing anything plus > preference for backward compatibility wherever it is possible. > > On Tue, 22 Apr 2025 at 7:00, Sam Tunnicliffe wrote: > >> +1 >> >> > On 17 Apr 2025,

Re: [VOTE] Release Apache Cassandra 5.0.4

+1 On Mon, Apr 7, 2025 at 7:37 AM Brandon Williams wrote: > Proposing the test build of Cassandra 5.0.4 for release. > > sha1: b81163b04b1d99036730ff233595d7bfb88611d1 > Git: https://github.com/apache/cassandra/tree/5.0.4-tentative > Maven Artifacts: > > https://repository.apache.org/content/rep

Re: CEP-15 Update

1. Just a quick reminder that CASSANDRA-18196 is where we had been tracking this previously with respect to things like the feature flag ( CASSANDRA-18195 ), etc. I'm not su

Re: Merging compaction improvements to 5.0

+1 on making this available in 5.0.xWe don’t have to find a default that’s perfect for every hardware configuration. I could understand an argument around disabling read ahead by default in 5.0, but that’s about it. No reason to withhold the capability from users.On Feb 12, 2025, at 9:36 PM, Tolber

Re: Meaningless emptiness and filtering

yte buffer in the DB? >>> >>> Anyway, I am kind of rambling here. I am of two minds. >>> I can see that this does seem like a silly distinction to have for some >>> types, so maybe we should just decide that in a CQL world, EMPTY means NULL >>> fo

Re: Meaningless emptiness and filtering

The case where allowsEmpty == true AND is meaningless == true is especially confusing. If I could design this from scratch, I would reject writes and filtering on EMPTY values for int and the other types where meaningless == true. (In other words, if we allow EMPTY, it is meaningful and queryable.

Re: [DISCUSS] Default Selection of 2i

fine.- Scott—MobileOn Feb 6, 2025, at 11:42 AM, Caleb Rackliffe <calebrackli...@gmail.com> wrote:System property works for me, even if I have to leave the default alone in 5.0.xOn Thu, Feb 6, 2025 at 1:34 PM Jeremiah Jordan <jeremiah.jor...@gmail.com> wrote: Rather than changing th

Re: [DISCUSS] Default Selection of 2i

A little hesitant of just changing it outright in a patch release. > > > > On Feb 6, 2025 at 1:10:28 PM, Caleb Rackliffe > wrote: > >> Hey everyone! >> >> I'll keep this short. SASI and later SAI, in lieu of anything resembling >> a query planner, hav

[DISCUSS] Default Selection of 2i

Hey everyone! I'll keep this short. SASI and later SAI, in lieu of anything resembling a query planner, have always just greedily returned a min long from Index#getEstimatedResultRows(), thereby stealing the right to be used to execute the query even when a legacy 2i is present on the relevant col

Re: [DISCUSS] 5.1 should be 6.0

Won't comment directly on the compatibility window (although I lean toward the status quo and just requiring upgrades from the latest patch version of a major release), but I think I've also arrived at a point where I'm not convinced running the Python upgrade tests pre-commit is an efficient use o

Re: [DISCUSS] Bracing style on trunk

I never should have mentioned this in the other thread in the first place. Just old/deep annoyance verbalized in an ultimately unhelpful way. It’s 15 years too late.On Jan 20, 2025, at 11:16 AM, Benedict wrote:These proposed refinements simply relax the wording of the style guide. That is, all cu

Re: Checkstyle as style contract for Cassandra

If we can bake it into the two IDEA settings that control class and method opening brace placement, WFMOn Jan 17, 2025, at 8:28 AM, Štefan Miklošovič wrote:I am sorry if I read this incorrectly but the vibe I am getting is that we are going to rework that. On Fri, Jan 17, 2025 at 3:22 PM Štefan M

Re: Checkstyle as style contract for Cassandra

> It would definitely have its costs, but it also wouldn't be a lot of toil if timed and executed surgically. It could just be done in trunk, after any huge outstanding feature branches are merged, and eventually it would just be a memory. There are forks out there, of course, and they would be af

Re: Checkstyle as style contract for Cassandra

> “why have we chosen a style guide that is hard to implement in these tools?” This has bothered me since I first looked at this code 14 years ago. How hard would it be to just stop doing the newline braces and be like nearly every other large Java project in existence? On Thu, Jan 16, 2025 at 1:

Re: [DISCUSS] Usage of "var" instead of types in the code

+1 to allowing in tests for now On Wed, Jan 8, 2025 at 12:51 PM Mick Semb Wever wrote: > > Jumping in, I'm ok to allow it in tests for a trial period too. I would > imagine in test methods especially it's of much less concern, where the > code is much simpler to read, and also safer to change t

Re: [DISCUSS] Index selection syntax for CASSANDRA-18112

I think we can handle manual index selection controls independently of the larger problem of query optimization. Once I have time to get to know CEP-39 and the DS approach a little better, I can open another thread here to start talking about those in the context of the problems we need to solve.

Re: [DISCUSS] Index selection syntax for CASSANDRA-18112

H OPTIONS would be useful for that too. That would let us add > any other new options to a SELECT without needing to modify the grammar > further. > > -Jeremiah > > On Dec 20, 2024 at 2:28:58 PM, Caleb Rackliffe > wrote: > >> Some of your are probably familiar wit

Re: [DISCUSS] Index selection syntax for CASSANDRA-18112

So that would look something like... SELECT ... FROM ... WHERE ... WITH OPTIONS = { 'exclude_indexes' : [, ] } On Fri, Dec 20, 2024 at 5:36 PM Caleb Rackliffe wrote: > You mean like to control the tokenization/analysis of query terms? > > On Fri, Dec 20, 2024 at 4:38

[DISCUSS] Index selection syntax for CASSANDRA-18112

Some of your are probably familiar with work in the DS fork to improve the selection of indexes for SAI queries in https://github.com/datastax/cassandra/commit/eeb33dd62b9b74ecf818a263fd73dbe6714b0df0#diff-2830028723b7f4af5ec7450fae2c206aeefa5a2c3455eff6f4a0734a85cb5424 . While I'm eagerly anticip

Re: [DISCUSS] 5.1 should be 6.0

I don't care what we call it as long as 4.1 -> 5.1/6.0 upgrades are possible. On Tue, Dec 10, 2024 at 1:28 PM David Capwell wrote: > Given our version support… if we do make this change does this imply users > must do the following to get to 6.0? > > 4.x upgrade to 5.0 > 5.0 upgrade to 6.0 > > S

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

+1 to Josh's refinement of JD's proposal On Tue, Dec 10, 2024 at 11:42 AM Josh McKenzie wrote: > +1 to this classification with one addition. I think we need to augment > this with formalization on what we do with features we don't recommend > people use (i.e. MV in their current incarnation). F

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

Let's say we went with the preview -> beta -> GA option. Does something like SASI stay in "experimental" while MV, transient replication, etc. move to "preview"? On Tue, Dec 10, 2024 at 11:30 AM Jeremiah Jordan wrote: > I agree with Aleksey and Patrick. We should define terminology and then > s

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

ca to be > replaced). This isn’t a “remove the feature” level bug though, given my > current understanding of it. If anything, it would be much more work than > just fixing the bug. > > If there’s a longer litany of breaking behaviours, let’s enumerate them > and consider marking the

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

I misspoke earlier about the feature gap. SAI supports queries legacy 2i does not, like numeric range queries.On Dec 10, 2024, at 9:29 AM, Caleb Rackliffe wrote:I think my point here is that the hidden table 2i implementation has known correctness/availability/operational/resource usage issues

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

deprecate 2i and recommend users switch to either global secondary indexes or SAI. Until then, I cannot see a good argument for it if we want to be considered a stable and mature product.On 10 Dec 2024, at 09:28, Caleb Rackliffe wrote:> I’m not convinced SAI has demonstrated a practical o

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

> I’m not convinced SAI has demonstrated a practical or theoretical capability to fully replace secondary indexes anyway. So it would be very premature to mark them deprecated. > If 2i indexes are to be marked as deprecated and SAI is beta, then what is actually the index implementation we stand b

[DISCUSS] Removing v30 and v3X from trunk in-JVM upgrade tests

The subject line probably says it all, but just to confirm, we won't be supporting 3.11 -> 5.1/trunk upgrades, correct? If that's correct, I'm going to go ahead and remove v30 and v3X from UpgradeTestBase and deal with the downstream changes in whatever way seems reasonable (without actually remov

Re: [DISCUSS] Usage of "var" instead of types in the code

Josh's example of "good" usage seems defensible, because the declared type is already obfuscated to Collection anyway, and my eyeballs are going to skip to the right anyway to see the instantiated type. I'm +0 on prohibiting it in non-test code, and -1 on prohibiting it in tests. On Tue, Oct 29, 2

Re: [DISCUSS] 5.0 Upgrades and CASSANDRA-19989

Just to close the loop, this is committed to 5.0 and trunk. On Wed, Oct 9, 2024 at 3:07 PM Caleb Rackliffe wrote: > Hey folks, > > I think we should probably not recommend 5.0 upgrades until > CASSANDRA-19989 <https://issues.apache.org/jira/browse/CASSANDRA-19989> > is rel

[DISCUSS] 5.0 Upgrades and CASSANDRA-19989

Hey folks, I think we should probably not recommend 5.0 upgrades until CASSANDRA-19989 is released. It could cause a significant amount of unnecessary read-repair activity on TTL'd data while an upgrade is in progress.

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

Tue, Oct 1, 2024 at 9:23 PM Jon Haddad wrote: > This also seems like an optimization. Why not go in 5.0? > > > On Tue, Oct 1, 2024 at 10:14 PM Jordan West wrote: > >> Agreed this would absolutely be a win. Dont see need for a flag either. >> >> On Tue,

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

Alrighty, with what looks like a fair amount of support, I'll declare CASSANDRA-19968 <https://issues.apache.org/jira/browse/CASSANDRA-19968> ready for some preliminary review. On Tue, Oct 1, 2024 at 2:41 PM Caleb Rackliffe wrote: > We did add CASSANDRA-18940 > <https://is

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

I think this is a good change over all. > > On Oct 1, 2024 at 1:51:10 PM, Jon Haddad wrote: > >> This seems like it's strictly a win. Doesn't sound to me like a flag is >> needed. >> >> On Tue, Oct 1, 2024 at 2:44 PM Caleb Rackliffe >> wrote: >

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

erty that switches this behavior. On Tue, Oct 1, 2024 at 12:43 PM Jeff Jirsa wrote: > > > > On Oct 1, 2024, at 10:28 AM, Caleb Rackliffe > wrote: > > > > Hello fellow secondary index enjoyers! > > > > If you're familiar with index queries, you proba

[DISCUSS] Secondary Indexes and Single-Partition Reads

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. This means that they bypass the digest read process that normal single-p

Re: CEP-15: Accord status

There is also a Jira to track pre-merge tasks here: https://issues.apache.org/jira/browse/CASSANDRA-18196 > On Sep 20, 2024, at 4:09 PM, Josh McKenzie wrote: > >  >> >> This presents an opportune moment for those interested to review the code. >> ... >> +88,341 −7,341 >> 1003 Files changed >

Re: [DISCUSS] CASSANDRA-13704 Safer handling of out of range tokens

The patches for this issue have gotten a +1 from Mick, and that meets our strict 2 committer rule, but I'm posting them here in case anyone else wants take a look: 4.0: https://github.com/apache/cassandra/pull/3526 4.1: https://github.com/apache/cassandra/pull/3539 5.0: https://github.com/apache/c

Re: [DISCUSS] CASSANDRA-13704 Safer handling of out of range tokens

manual operator's involvement. > > How about we also enhance Cassandra to automatically detect and fix the > token ownership mismatch between StorageService and Gossip cache? More > details to this ticket: > https://issues.apache.org/jira/browse/CASSANDRA-18758 > > Jaydee

Re: [DISCUSS] CASSANDRA-13704 Safer handling of out of range tokens

If it makes anyone feel better, 2600 of the 3600-lines of this patch are tests (and the rest is minor refactoring of the verb handlers). Anyway, glad to see a ton of participation here. I'll get back into implementation space today, and start dealing with review feedback as it comes in... P.S. I

Re: [DISCUSS] CASSANDRA-13704 Safer handling of out of range tokens

don Williams wrote: > > On Thu, Sep 12, 2024 at 1:13 PM Caleb Rackliffe > wrote: >> >> I think I can count at least 4 people on this thread who literally have lost >> sleep over this. > > Probably good examples of not being the majority though, heh. >

Re: [DISCUSS] CASSANDRA-13704 Safer handling of out of range tokens

I think I can count at least 4 people on this thread who literally have lost sleep over this. > On Sep 12, 2024, at 1:07 PM, Brandon Williams wrote: > > On Thu, Sep 12, 2024 at 11:52 AM Josh McKenzie > wrote: >> >> More or less surprising than learning that they've been at risk of or >> ac

Re: [DISCUSS] CASSANDRA-13704 Safer handling of out of range tokens

s in 5.0. I’d probably reject by default in 5.0.1.  4.0 / 4.1 - if we treat this like a fix for latent opportunity for data loss (which it implicitly is), I guess? > On Sep 12, 2024, at 9:46 AM, Brandon Williams <dri...@gmail.com> wrote: > > On Thu, Sep 12, 2024 at 11:41 AM Caleb

Re: [DISCUSS] CASSANDRA-13704 Safer handling of out of range tokens

ess vs availability, but even that contrast isn't very honest. Being available isn't productive if we're not correct. On Thu, Sep 12, 2024 at 11:46 AM Brandon Williams wrote: > On Thu, Sep 12, 2024 at 11:41 AM Caleb Rackliffe > wrote: > > > > Are you oppose

Re: [DISCUSS] CASSANDRA-13704 Safer handling of out of range tokens

wrong view > of the cluster for short periods of time while bootstrapping that this > would have prevented. > > Chris > > On Thu, Sep 12, 2024 at 11:16 AM Brandon Williams > wrote: > >> On Thu, Sep 12, 2024 at 11:07 AM Caleb Rackliffe >> wrote: >> > &g

[DISCUSS] CASSANDRA-13704 Safer handling of out of range tokens

Until we release TCM, it will continue to be possible for nodes to have a divergent view of the ring, and this means operations can still be sent to the wrong nodes. For example, writes may be sent to nodes that do not and never will own that data, and this opens us up to rather devious silent data

Re: [VOTE] Release Apache Cassandra 4.1.6

+1 to proceeding with a simple upgrade note in NEWS On Wed, Jul 31, 2024 at 12:50 PM Josh McKenzie wrote: > Unfortunately, I can not immediately see a good way to provide the > critical bugfix of CASSANDRA-19534 > , affecting all > Cassandra

Re: [DISCUSS] Removing support for deterministic table IDs

table is (TableId, Epoch)… and that… is annoying... > > On Jul 30, 2024, at 3:47 PM, Jordan West wrote: > > Understood. Nits aside I have no objection to your plan. > > Jordan > > On Tue, Jul 30, 2024 at 15:42 Caleb Rackliffe > wrote: > >> I think the main moti

Re: [DISCUSS] Removing support for deterministic table IDs

Jordan > > On Tue, Jul 30, 2024 at 15:04 Caleb Rackliffe > wrote: > >> To summarize all this noise I've created, the plan would be... >> >> 1.) Leave CQL WITH id intact. >> 2.) Deprecate and WARN on *use_deterministic_table_id *in 5.0.x. >> 3.)

Re: [DISCUSS] Removing support for deterministic table IDs

To summarize all this noise I've created, the plan would be... 1.) Leave CQL WITH id intact. 2.) Deprecate and WARN on *use_deterministic_table_id *in 5.0.x. 3.) Ignore and WARN on *use_deterministic_table_id *in 5.1. 4.) Profit On Tue, Jul 30, 2024 at 4:46 PM Caleb Rackliffe wrote:

Re: [DISCUSS] Removing support for deterministic table IDs

No intention of touching WITH id in CQL On Tue, Jul 30, 2024 at 4:10 PM Caleb Rackliffe wrote: > To clarify, my plan was to deprecate in Config/JMX and ignore it, not > remove it entirely so it breaks existing YAMLs and JMX clients. > > This should be fine, if I'm reading

Re: [DISCUSS] Removing support for deterministic table IDs

; don’t really need the feature anymore. I am fine with deprecating the > feature, but removing would be a breaking change for anyone that had that > config in place, so not a fan of breaking the config interface. > > On Jul 30, 2024, at 1:38 PM, Caleb Rackliffe > wrote: > > I'd

[DISCUSS] Removing support for deterministic table IDs

I'd like to propose removing deterministic table IDs for new *user* tables and views in trunk. With TCM in place, it looks like the reason we added *use_deterministic_table_id*, concurrent table creations, is no longer a concern. Thoughts? Objections?

Re: [DISCUSS] Replace airlift/airline library with Picocli

With concerns around licensing all but resolved, I'd support Pico as our airline replacement. It looks like it would entail the least risky migration, is being actively maintained, will make the development of a number of planned enhancements easier, etc. On Tue, Jul 16, 2024 at 10:40 AM Jeff Jirs

Re: [DISCUSS] Feature branch to update a nodetool obsolete dependency (airline)

eople can >>>>> sign >>>>> off if they care or not. >>>>> >>>>> I wouldn’t create this thread until you settle on which one you wish >>>>> to move forward with. >>>>> >>>>> Is adding the PicoCLI li

Re: [DISCUSS] Feature branch to update a nodetool obsolete dependency (airline)

+1 on picocli RE the feature branch, I would just maintain the feature branch in your own fork to break out whatever "reviewable units" of code you want. When all the incremental review is done (I have no problem going back and forth), squash everything together, do whatever additional testing you

Re: [DISCUSS] Increments on non-existent rows in Accord

later, but I suspect that with our > one shot behavior it would get mixed up by multiple attempts to insert if > not exists and then update the same row to achieve upsert. > > Ariel > On Thu, Jun 20, 2024, at 4:54 PM, Caleb Rackliffe wrote: > > We had a bug re

Re: [DISCUSS] Increments on non-existent rows in Accord

. Furthermore, there is no means of knowing which action occurred.”That being the case, I think the second option you mention is what keeps consistency with the UPDATEs out of the transaction.Kind regards,BernardoOn Jun 20, 2024, at 1:54 PM, Caleb Rackliffe wrote:We had a bug report a while back from Luis E

[DISCUSS] Increments on non-existent rows in Accord

We had a bug report a while back from Luis E Fernandez and team in CASSANDRA-18988 around the behavior of increments/decrements on numeric fields for non-existent rows. Consider the following, wich can be run on the cep-15-accord branch: CREA

Re: [DISCUSS] Stream Pipelines on hot paths

+1 On Thu, May 30, 2024 at 11:29 AM Benedict wrote: > Since it’s related to the logging discussion we’re already having, I have > seen stream pipelines showing up in a lot of traces recently. I am > surprised; I thought it was understood that they shouldn’t be used on hot > paths as they are not

Re: [DISCUSS] Adding experimental vtables and rules around them

The two-part proposal of 1.) table-level self-identification of experimental status and 2.) a global config flag that determines what to do when querying those might work. I guess the only thing you can't do there is ignore warnings from a specific experimental table, since that's controlled in cod

Re: [EXTERNAL] Re: [Discuss] Generic Purpose Rate Limiter in Cassandra

m this thread >>> into a draft seems like a solid next step. >>> >>> On Wed, Feb 7, 2024, at 12:31 PM, Jaydeep Chovatia wrote: >>> >>> I see a lot of great ideas being discussed or proposed in the past to >>> cover the most common rate limiter can

Re: [DISCUSS] Donating easy-cass-stress to the project

I do have some familiarity w/ the codebase, and I could help support it in a minor capacity. (Reviews, small fixes, etc.) Probably not something I could spend hours on every week.On Apr 25, 2024, at 5:11 PM, Jon Haddad wrote:I should probably have noted - since TLP is no more, I renamed tlp-stres

Re: [DISCUSS] NULL handling and the unfrozen collection issue

The easiest way to check out how Accord uses IS NULL and IS NOT NULL is to look at the examples in the cep-15-accord branch: https://github.com/apache/cassandra/blob/cep-15-accord/test/distributed/org/apache/cassandra/distributed/test/accord/AccordCQLTestBase.java tl;dr We did indeed try to go wi

Re: [DISCUSSION] Replace the Config class instance with the tree-based framework

> I kinda feel this should be separated as we can and do do this today but the reason we have not grouped is not due to the framework we use but more “what makes sense to group” I think that's more or less correct. The critical path thing here is getting to consensus (in CASSANDRA-17292

Re: [DISCUSS] Cassandra 5.0 support for RHEL 7

Just created CASSANDRA-19467 <https://issues.apache.org/jira/browse/CASSANDRA-19467> On Tue, Mar 12, 2024 at 1:45 PM Caleb Rackliffe wrote: > Alright, so there has been a little conversation in ASF Slack here: > https://the-asf.slack.com/archives/CK23JSY2K/p1710255088441369 >

Re: [DISCUSS] Cassandra 5.0 support for RHEL 7

7;ll warn anyone who does run cqlsh w/ those versions that they are EOL, support may be removed in a future C* release, and they may be used on an "as is" basis. I'll get a Jira up shortly... On Mon, Mar 11, 2024 at 8:51 PM Caleb Rackliffe wrote: > I did a quick experiment to re

Re: [DISCUSS] Cassandra 5.0 support for RHEL 7

I did a quick experiment to revert all the bits that require 3.8+ in the server codebase (while leaving 3.29.0 in place), and I don't see anything breaking in the tests on trunk.

Re: [DISCUSS] Cassandra 5.0 support for RHEL 7

in cqlsh is the sole reason > we've bumped to 3.7 and 3.8 to support that python driver. That correct > Andres / Brandon? > > On Mon, Mar 11, 2024, at 1:22 PM, Caleb Rackliffe wrote: > > The vector issues itself was a simple error message change: > https://github.com/datastax/pyt

Re: [DISCUSS] Cassandra 5.0 support for RHEL 7

The vector issues itself was a simple error message change: https://github.com/datastax/python-driver/commit/e90c0f5d71f4cac94ed80ed72c8789c0818e11d0 Was there something else in 3.29.0 that actually necessitated the move to a floor of Python 3.8? Do we generally change runtime requirements in mino

Re: [DISCUSS] What SHOULD we do when we index an inet type that is ipv4?

> if an inet type column is a partition key, can I write to it in IPv4 and then query it with IPv6 and find the record? You can't...however... Especially when the original/existing behavior here was possibly not all that well-conceived, I think it would at least be a good idea to maintain an *abi

Re: [DISCUSS] What SHOULD we do when we index an inet type that is ipv4?

Yeah, what we have with inet is much like if we had a type like "numeric" that allowed you to write both ints and doubles. If we had actual "inet4" and "inet6" types, SAI would have been able to index them as fixed length values without doing the 4 -> 16 byte conversion. Given SAI could easily chan

Re: [EXTERNAL] Re: [Discuss] Generic Purpose Rate Limiter in Cassandra

nt domains > (client -> coordinator, coordinator -> replica, internode with other > operations, etc) at surprising times and should be considered more > holistically? > > On Tue, Jan 30, 2024, at 12:31 AM, Caleb Rackliffe wrote: > > I almost forgot CASSANDRA-15817, whi

Re: [EXTERNAL] Re: [Discuss] Generic Purpose Rate Limiter in Cassandra

I almost forgot CASSANDRA-15817, which introduced reject_repair_compaction_threshold, which provides a mechanism to stop repairs while compaction is underwater.On Jan 26, 2024, at 6:22 PM, Caleb Rackliffe wrote:Hey all,I'm a bit late to the discussion. I see that we've already

Re: [EXTERNAL] Re: [Discuss] Generic Purpose Rate Limiter in Cassandra

Hey all, I'm a bit late to the discussion. I see that we've already discussed CASSANDRA-15013 and CASSANDRA-16663 at least in passing. Having written the latter, I'd be the first to admi

Re: [DISCUSS] CEP-39: Cost Based Optimizer

I think I hinted at this in my first response, but just to clarify, I would be interested to see this work broken up as much as possible into a.) the set of things we can do without coordinator involvement (statistical optimization for index and filtering queries) and b.) the set of things where co

Re: [DISCUSS] CEP-39: Cost Based Optimizer

What would the relationship between our present query tracing apparatus and EXPLAIN ANALYZE look like? On Thu, Dec 21, 2023 at 4:24 PM Caleb Rackliffe wrote: > > We are also currently working on some SAI features that need cost based > optimization. > > I don't even think we

Re: [DISCUSS] CEP-39: Cost Based Optimizer

> We are also currently working on some SAI features that need cost based optimization. I don't even think we have to think about *new* SAI features to see where it will benefit from further *local* optimization, and I'm sympathetic to that happening in the context of a larger framework, as long a

Re: Harry in-tree (Forked from "Long tests, Burn tests, Simulator tests, Fuzz tests - can we clarify the diffs?")

+1 Agree w/ all the justifications mentioned above. As a reviewer on CASSANDRA-19210 , my goals were to a.) look at the directory, naming, and package structure of the ported code, b.) make sure IDE integration was working, and c.) make sure

Re: Welcome Mike Adamson as Cassandra committer

Congratulations! Very well deserved. On Fri, Dec 8, 2023 at 10:33 AM Mick Semb Wever wrote: > Congrats Mike !! > >>

Re: [DISCUSS] CASSANDRA-18940 SAI post-filtering reads don't update local table latency metrics

. > > On Dec 1, 2023, at 12:50 PM, Caleb Rackliffe > wrote: > >  > So the plan would be to have local "Read" and "Range" remain unchanged in > TableMetrics, but have a third "SAIRead" (?) just for SAI post-filtering > read SinglePartitionReadComm

Re: [DISCUSS] CASSANDRA-18940 SAI post-filtering reads don't update local table latency metrics

client level metrics, not > regular reads. So grouping them into the regular read metrics at the lower > level seems confusing to me in that sense as well. > > As an operator I want to know how my SAI reads and normal reads are > performing latency wise separately. > > -Jeremi

Re: [DISCUSS] CASSANDRA-18940 SAI post-filtering reads don't update local table latency metrics

Option 1 would be my preference. Seems both useful to have a single metric for read load against the table and a way to break out SAI reads specifically. On Fri, Dec 1, 2023 at 11:00 AM Mike Adamson wrote: > Hi, > > We are looking at adding SAI post-filtering reads to the local table > metrics a

Re: [VOTE] Release Apache Cassandra 5.0-beta1 (take2)

+1 (nb) > On Dec 1, 2023, at 7:32 AM, Mick Semb Wever wrote: > >  > > Proposing the test build of Cassandra 5.0-beta1 for release. > > sha1: 87fd1fa88a0c859cc32d9f569ad09ad0b345e465 > Git: https://github.com/apache/cassandra/tree/5.0-beta1-tentative > Maven Artifacts: > https://repository.ap

Re: [VOTE] Release Apache Cassandra 5.0-beta1

> So in the context of this thread, if I want to try out SAI for example, I don't care as much about consistency edge cases around coordinators or replicas or read repair. That would apply to 19018, not 19011, which is a critical functionality issue. On Wed, Nov 29, 2023 at 12:49 PM Jeremy Hanna

Re: [VOTE] Release Apache Cassandra 5.0-beta1

If the consensus is that meaningful community testing will occur in the week between "beta1 but SAI is broken, friends" and "ok, beta2, it's fixed now, go for it"...then go for it. On Tue, Nov 28, 2023 at 12:40 PM Patrick McFadin wrote: > JD, that wasn't my point. It feels like we are treating a

Re: [VOTE] Release Apache Cassandra 5.0-beta1

I'm fine w/ alpha2 now and beta1 once we resolve 19011. On Tue, Nov 28, 2023 at 12:36 PM Benjamin Lerer wrote: > -1 based on the problems raised by Caleb. > > I would be fine with releasing that version as an alpha as Jeremiah > proposed. > > As of this time, I'm also not aware of a user of the

Re: [VOTE] Release Apache Cassandra 5.0-beta1

Just to update this thread, Mike has identified the root cause of 19011 and in the process uncovered 2 additional very closely related issues. (Fantastic job fuzzing there!) Fixes for all three issues are in hand, and he continues to test.After some conversation w/ Mick, Alex, and Mike, I feel like

Re: [DISCUSS] Update default disk_access_mode to mmap_index_only on 5.0

Added one nit to the PR. Otherwise, this is awesome :) On Wed, Nov 15, 2023 at 11:01 AM Jordan West wrote: > I would also like to back this proposal. We change this default because > several incidents have occurred by leaving the default of auto. There are > rare cases where auto/mmap is the bet

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

...or like the end of January. Either way, feel free to ignore the "aside" :) On Mon, Oct 23, 2023 at 12:53 PM Caleb Rackliffe wrote: > Kind of in the same place as Benedict/Aleksey. > > If we release a 5.1 in, let's say...March of next year, the number of 5.0 >

Re: Push TCM (CEP-21) and Accord (CEP-15) to 5.1 (and cut an immediate 5.1-alpha1)

Kind of in the same place as Benedict/Aleksey. If we release a 5.1 in, let's say...March of next year, the number of 5.0 users is going to be very minimal. Nobody is going to upgrade anything important from now through the first half of January anyway, right? They're going to be making sure their

Re: [VOTE] Accept java-driver

+1 On Tue, Oct 3, 2023 at 2:49 PM Sylvain Lebresne wrote: > +1 > -- > Sylvain > > > On Tue, Oct 3, 2023 at 8:43 PM Jon Haddad > wrote: > >> +1 >> >> >> On 2023/10/03 04:52:47 Mick Semb Wever wrote: >> > The donation of the java-driver is ready for its IP Clearance vote. >> > https://incubator.a

Re: [DISCUSS] Backport CASSANDRA-18816 to 5.0? Add support for repair coordinator to retry messages that timeout

+1 on a 5.0 backport On Wed, Sep 20, 2023 at 2:26 PM Brandon Williams wrote: > I think it could be argued that not retrying messages is a bug, I am > +1 on including this in 5.0. > > Kind Regards, > Brandon > > On Tue, Sep 19, 2023 at 1:16 PM David Capwell wrote: > > > > To try to get repair mo

Re: [DISCUSS] Update default disk_access_mode to mmap_index_only on 5.0

+100 to this We'd have to come up w/ a pretty compelling counterexample to NOT switch the default to mmap_index_only at this point. On Wed, Sep 6, 2023 at 11:40 AM Brandon Williams wrote: > Given https://issues.apache.org/jira/browse/CASSANDRA-17237 I think it > makes sense. At the least I thi

Re: Tokenization and SAI query syntax

t;> indexing is going to look like or the shape it's going to take for awhile, >> so backing ourselves into any of the 3 corners above right now feels very >> premature to me. >> >> So I'm coming around to the expr / method call approach to preserve that >>

Re: [DISCUSS] CASSANDRA-18743 Deprecation of metrics-reporter-config

+1 > On Aug 11, 2023, at 8:10 AM, Brandon Williams wrote: > > +1 > > Kind Regards, > Brandon > >> On Fri, Aug 11, 2023 at 8:08 AM Ekaterina Dimitrova >> wrote: >> >> >> “ The rationale for this proposed deprecation is that the upcoming 5.0 >> release is a good time to evaluate dependencie

Re: Tokenization and SAI query syntax

something so >>> that SASI indexes auto convert to SAI, this gives even more weight to my >>> point regarding how differing behavior for the same syntax can lead to >>> issues. Imo the best case scenario results in the user not even noticing >>> their

Re: Tokenization and SAI query syntax

nario results in the user not even noticing >> their indexes have changed. >> >> An (maybe better?) alternative is to add a flag to the index >> configuration for "compatibility mod", which might address the concerns >> around using an equality operator wh

Re: Tokenization and SAI query syntax

ASI and SAI both support use the same syntax, even > if it means there's two ways of writing the same query. To use Caleb's > example, this would mean supporting both LIKE and the `expr` column. > >> > >> Jon > >> > >>>> On 2023/08/01 19:17:11 Caleb

Re: Tokenization and SAI query syntax

Here are some additional bits of prior art, if anyone finds them useful: The Stratio Lucene Index - https://github.com/Stratio/cassandra-lucene-index#examples Stratio was the reason C* added the "expr" functionality. They embedded something similar to ElasticSearch JSON, which probably isn't my

  1   2   3   >