On Tue, May 14, 2024 at 10:05 AM Mick Semb Wever wrote:
>
> Ok, so we're got confidence now on how to approach this, confirmation from
> the project's maintainers supporting it, and interest from a handful of
> people interested in maintaining and contributing to the project.
>
Did you talk to t
Does anyone call out the need for a new CEP for bringing the gocql into the
Driver's subproject ?
> My suggestion is that this falls under CEP-8, even if it is not DataStax
> donating this particular codebase, the process is largely the same and it is
> the Drivers subproject receiving it.
+1 t
>
> It would be a lot more constructive to apply our brains towards solving an
> interesting problem than pointing out all its potential flaws based on gut
> feelings.
It is not simply a gut feeling, Jon. This change impacts read, write,
indexing, storage, compaction, repair... The risk and cost
Personally, I don't think that something being scary at first glance is a
good reason not to explore an idea. The scenario you've described here is
tricky but I'm not expecting it to be any worse than say, SAI, which (the
last I checked) has O(N) complexity on returning result sets with regard to
Ok, so we're got confidence now on how to approach this, confirmation from
the project's maintainers supporting it, and interest from a handful of
people interested in maintaining and contributing to the project.
The proposed plan forward is…
We will go through a round of collecting CLAs along wi
Ranged update sounds like a disaster for compaction and read performance.
Imagine compacting or reading some SSTables in which a large number of
overlapping but non-identical ranges were updated with different values.
It gives me a headache by just thinking about it.
Ranged delete is much sim
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 would prevent a range write that
> functions the same way as a range tom
[Note: You're receiving this email because you are subscribed to one
or more project dev@ mailing lists at the Apache Software Foundation.]
We are very close to Community Over Code EU -- check out the amazing
program and the special discounts that we have for you.
Special discounts
You still hav
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 work
Hi all,
As I have mentioned on many other projects mailing lists, that also had the
habit of counting "implicit votes" ... at the ASF there is no such thing as an
"implicit vote" on a release.
Feel free to add an "this email also counts as my +1" to the initial VOTE email
or even better, cast
Range restrictions (>, >=, =<, < and BETWEEN) do not work on UPDATEs. They
do work on DELETE because under the hood C* they get translated into range
tombstones.
Le mar. 14 mai 2024 à 02:44, David Capwell a écrit :
> I would also include in UPDATE… but yeah, <3 BETWEEN and welcome this work.
>
>
11 matches
Mail list logo
