Ariel, having it in C* process makes sense to me.
Please correct me if I'm wrong here, but shouldn't using ZCS to transfer
have no distinguishable difference in overhead from doing it using the
sidecar? Since the underlying call is sendfile, never hitting userspace, I
can't see why we'd opt for
Kind Regards,
> Brandon
>
> On Thu, Apr 25, 2024 at 9:38 AM Jon Haddad wrote:
> >
> > I've been asked by quite a few people, both in person and in JIRA [1]
> about contributing easy-cass-stress [2] to the project. I've been happy to
> maintain the project myself over the ye
ustify creating a subproject
>
> And if there’s not 2-3 people expressing interest, even pulling it into
> the main project seems risky
>
> So: besides Jon, who in the community expects/desires to maintain this
> going forward?
>
> On Apr 25, 2024, at 5:55 PM, Jon Haddad
to make my life harder to move under the project umbrella. I don't
want to go from my wild west style of committing whatever I want to waiting
around for days or weeks to get features committed.
Project rename happened here:
commit 6c9493254f7bed57f19aaf5bda19f0b7734b5333
Author: Jon Haddad
I can’t see a good reason not to support it. Seems like extra work to avoid
with no benefit.
—
Jon Haddad
Rustyrazorblade Consulting
rustyrazorblade.com
On Thu, Apr 25, 2024 at 7:16 AM Štefan Miklošovič <
stefan.mikloso...@gmail.com> wrote:
> Can you elaborate on intentionally not s
I've been asked by quite a few people, both in person and in JIRA [1] about
contributing easy-cass-stress [2] to the project. I've been happy to
maintain the project myself over the years but given its widespread use I
think it makes sense to make it more widely available and under the
project's
+1
On Thu, May 2, 2024 at 9:37 AM Brandon Williams
wrote:
> Proposing the test build of Cassandra 4.1.5 for release.
>
> sha1: 6b134265620d6b39f9771d92edd29abdfd27de6a
> Git: https://github.com/apache/cassandra/tree/4.1.5-tentative
> Maven Artifacts:
>
>
Brandon, myself, and Mick are +1 PMC votes.
On Tue, May 7, 2024 at 4:46 PM Justin Mclean wrote:
> Hi,
>
> In the vote thread, there are only two explicit +1 PMC votes. In the
> future, it would be best to wait for three +1 votes, or the release manager
> should also vote.
>
> Kind Regards,
>
Justin, I just re-read what you wrote, and I think you're saying that
you're not counting Brandon's original email as a vote? Is that correct?
Jon
On Tue, May 7, 2024 at 6:01 PM Jon Haddad wrote:
> Brandon, myself, and Mick are +1 PMC votes.
>
> On Tue, May 7, 2024 at 4:46 PM Just
024 16:59, Benjamin Lerer wrote:
>
> It should be like range tombstones ... in much worse ;-). A tombstone is a
> simple marker (deleted). An update can be far more complex.
>
> Le mar. 14 mai 2024 à 15:52, Jon Haddad a écrit :
>
>> Is there a technical limitation that
Is there a technical limitation that would prevent a range write that
functions the same way as a range tombstone, other than probably needing a
version bump of the storage format?
On Tue, May 14, 2024 at 12:03 AM Benjamin Lerer wrote:
> Range restrictions (>, >=, =<, < and BETWEEN) do not
gut feeling, Jon. This change impacts read, write,
> indexing, storage, compaction, repair... The risk and cost associated with
> it are pretty significant and I am not convinced at this point of its
> benefit.
>
> Le mar. 14 mai 2024 à 19:05, Jon Haddad a écrit :
>
> Personally, I don't
201 - 212 of 212 matches
Mail list logo
