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

+1 Jeremiah D Jordan 于2022年12月10日 周六上午5:59写道： > +1 nb > > > On Dec 7, 2022, at 3:40 PM, Mick Semb Wever wrote: > > > Proposing the (second) test build of Cassandra 4.1.0 for release. > > sha1: f9e033f519c14596da4dc954875756a69aea4e78 > Git: >

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

+1 nb > On Dec 7, 2022, at 3:40 PM, Mick Semb Wever wrote: > > > Proposing the (second) test build of Cassandra 4.1.0 for release. > > sha1: f9e033f519c14596da4dc954875756a69aea4e78 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.1.0-tentative > Maven

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

+1 On Fri, Dec 9, 2022 at 12:21 PM Sam Tunnicliffe wrote: > +1 > > On 7 Dec 2022, at 21:40, Mick Semb Wever wrote: > > > Proposing the (second) test build of Cassandra 4.1.0 for release. > > sha1: f9e033f519c14596da4dc954875756a69aea4e78 > Git: >

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

+1 > On 7 Dec 2022, at 21:40, Mick Semb Wever wrote: > > > Proposing the (second) test build of Cassandra 4.1.0 for release. > > sha1: f9e033f519c14596da4dc954875756a69aea4e78 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.1.0-tentative > Maven

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

+1 On Fri, 9 Dec 2022 at 15:41, Josh McKenzie wrote: > +1 > > On Fri, Dec 9, 2022, at 10:28 AM, Marcus Eriksson wrote: > > +1 > > On Wed, Dec 07, 2022 at 10:40:21PM +0100, Mick Semb Wever wrote: > > Proposing the (second) test build of Cassandra 4.1.0 for release. > > > > sha1:

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

+1 On Fri, Dec 9, 2022, at 10:28 AM, Marcus Eriksson wrote: > +1 > > On Wed, Dec 07, 2022 at 10:40:21PM +0100, Mick Semb Wever wrote: > > Proposing the (second) test build of Cassandra 4.1.0 for release. > > > > sha1: f9e033f519c14596da4dc954875756a69aea4e78 > > Git: > >

Re: Aggregate functions on collections, collection functions and MAXWRITETIME

> I wonder if there’s any value in deciding on a general approach to guide > these discussions in future? Are we aiming to look like SQL as we evolve, and > if so which products do we want to be informed by? CQL's proximity to SQL is a blessing and a curse IMO. How close do we expect ourselves

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

+1 On Wed, Dec 07, 2022 at 10:40:21PM +0100, Mick Semb Wever wrote: > Proposing the (second) test build of Cassandra 4.1.0 for release. > > sha1: f9e033f519c14596da4dc954875756a69aea4e78 > Git: > https://gitbox.apache.org/repos/asf?p=cassandra.git;a=shortlog;h=refs/tags/4.1.0-tentative > Maven

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

+1 Checked - signing correct - checksums are correct - source artefact builds (JDK 8+11) - binary artefact runs (JDK 8+11) - debian package runs (JDK 8+11) - debian repo runs (JDK 8+11) - redhat* package runs (JDK 8+11) - redhat* repo runs (JDK 8+11) On Fri, 9 Dec 2022 at 16:06, Matt Fleming

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

+1 Kind Regards, Brandon On Wed, Dec 7, 2022 at 3:41 PM Mick Semb Wever wrote: > > > Proposing the (second) test build of Cassandra 4.1.0 for release. > > sha1: f9e033f519c14596da4dc954875756a69aea4e78 > Git: >

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

Me and Marianne finished running all the tests for Paxos V2 with the bug fixes from CASSANDRA-18086 and the results for the 100 partitions are definitely better than V1. For the larger partitions (1000, 1), the results for V2 are comparable and overall V2 did not have any performance

Re: [VOTE] Release Apache Cassandra 4.1.0 GA

Hi everyone, Matt and I finished running all the tests for V2 with the bug fixes from CASSANDRA-18086 and the results for the 100 partitions are definitely better than V1. For the larger partitions (1000, 1), the results for V2 are

Re: Aggregate functions on collections, collection functions and MAXWRITETIME

Why would that require a fancy query optimiser? It doesn’t seem like it would be much more difficult than modifying our function binding rules and having a specialised version. > On 9 Dec 2022, at 13:26, Andrés de la Peña wrote: > >  > Note that specialized collection functions are also an

Re: Aggregate functions on collections, collection functions and MAXWRITETIME

Note that specialized collection functions are also an opportunity for optimization. For example, COLLECTION_COUNT reads only the first bytes of a serialized collection, since those bytes contain the number of elements in that collection. The most simple implementation of COUNT(UNNEST(collection))

Re: Aggregate functions on collections, collection functions and MAXWRITETIME

Right, this is basically my view - it can be syntactic sugar for UNNEST subqueries as and when we offer those (if not now), but I think we should be able to apply any UDA or aggregate to collections with some syntax that’s ergonomic. I don’t think APPLY is the right way to express it, my

Re: Aggregate functions on collections, collection functions and MAXWRITETIME

The idea isn’t that dissent is important, but that interrogating changes like this in a broader forum is valuable - and should be the norm. Nobody is suggesting that anything untoward has happened previously, only that we can do better going forward. It was by chance that I saw one of these

Re: Aggregate functions on collections, collection functions and MAXWRITETIME

I still think that semantically it makes sense to have a function that applies an aggregate to various collection types. So rather than building ARRAY_MAX do APPLY(MAX, column)) or APPLY(MAX(column)) it is clear what is being requested and APPLY can be the source of truth for which aggregate

Re: Aggregate functions on collections, collection functions and MAXWRITETIME

Indeed this discussion is useful now that we know that there is dissension about these changes. However, as those changes were happening none of the persons involved on them felt the need of a discuss thread, and I opened this thread as soon as Benedict objected the changes. I think this is

Re: Review requested: Add downgradesstables

Hi, The feature looks useful to me Could you add the pull request address to the ticket and summarize the features it is going to provide? Thank you, - - -- --- - - Jacek Lewandowski On Fri, Dec 9, 2022 at 10:13 AM Claude Warren, Jr via dev < dev@cassandra.apache.org>

Review requested: Add downgradesstables

https://github.com/apache/cassandra/pull/2045 https://issues.apache.org/jira/browse/CASSANDRA-8928 This is a work in progress and I am looking for some feedback. This fix appears to work correctly. But I think the placement of the v3 directory is probably not the best and perhaps should be

Re: [DISCUSSION] Cassandra's code style and source code analysis

+1 avoid star rule On Wed, Dec 7, 2022 at 5:30 PM Maxim Muzafarov wrote: > Dear community, > > > I have created the epic with code-style activities to track the progress: > https://issues.apache.org/jira/browse/CASSANDRA-18090 > > In my understanding, there is no need to format whole the code