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

+1 Sounds like a great change that will help us unify around a common testing paradigm, and even pave the path to in-tree load testing plus integrated correctness checking which would be extremely valuable! -Joey On Thu, Dec 21, 2023 at 1:35 PM Caleb Rackliffe wrote: > +1 > > Agree w/ all the

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

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 have to think about

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

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

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

Hey folks, I am mostly done with a patch that brings Harry in-tree [1]. I will trigger one more CI run overnight, and my intention was to merge it some time soon, but I wanted to give a fair warning here, since this is a relatively large patch. Good news for everyone that it: a) touches no

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

> we are already late. We have several features running in production that we > chose to not open source yet because implementing phase 1 of the CEP would > have heavily simplify their designs. The cost of developing them was much > higher than what it would have been if the CEP had already

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

Hey German, To clarify things, we intend to push cardinalities across nodes, not costs. It will be up to the Cost Model to estimate cost based on those cardinalities. We will implement some functionalities to collect costs on query execution to be able to provide them as the output of EXPLAIN

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

Hi Scott, Thanks for your feedback. If I am not mistaken the main concern in your email is that without features that will heavily benefit from the optimizer, this work will not bring much. You are, therefore, under the impression that this work is one or two years early. In my perspective, we

Re: CEP-21 - testing changing IP addresses

Hi, On Thu, Dec 21, 2023 at 09:45:23AM +, Paul Chandler via dev wrote: > Hi all, > > We run some large clusters using Kubernetes and recently ran into an issue on > 4.0.x, so I decided to look at 5.1 and see if TCM fixes the issue. > > However what we found was there are a number of new

CEP-21 - testing changing IP addresses

Hi all, We run some large clusters using Kubernetes and recently ran into an issue on 4.0.x, so I decided to look at 5.1 and see if TCM fixes the issue. However what we found was there are a number of new issues with TCM when a node is stopped then restarts with a new ip address, something