I second Patrick about the parties and all that… Thanks, Simon for all your
work! I am excited to see what’s next from you as I am sure it will be
awesome!
Cheers!
On Thu, 16 May 2024 at 14:50, Jon Haddad wrote:
> Benjamin, I’m +1 on adding BETWEEN, thanks for bringing this up.
>
> To all, my i
Benjamin, I’m +1 on adding BETWEEN, thanks for bringing this up.
To all, my intention wasn’t to suggest we add support for update between
via range writes at the same time, if it came across that way i apologize
for the confusion.
Josh, thanks for the suggestion. If I feel inspired to discuss wit
> More of a "how could we technically reach mars?" discussion than a "how we
> get congress to authorize a budget to reach mars?"
Wow - that is genuinely a great simile. Really good point.
To Jeff's point - want to kick off a [DISCUSS] thread referencing this thread
Jon so we can take the conver
You can remove the shadowed values at compaction time, but you can’t ever fully
propagate the range update to point updates, so you’d be propagating all of the
range-update structures throughout everything forever. It’s JUST like a range
tombstone - you don’t know what it’s shadowing (and can’t,
Thanks for the reply Benjamin, makes sense to me. We can always add it later
if it makes sense later, don’t need now in UPDATE
> On May 15, 2024, at 7:44 AM, Jon Haddad wrote:
>
> I was trying to have a discussion about a technical possibility, not a cost
> benefit analysis. More of a "how c
I was trying to have a discussion about a technical possibility, not a cost
benefit analysis. More of a "how could we technically reach mars?"
discussion than a "how we get congress to authorize a budget to reach mars?"
Happy to talk about this privately with anyone interested as I enjoy a
techni
> 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?
The technical limitation would be cost/benefit due to how this intersects w/our
architecture I think.
Range
>
> 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
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
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
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.
>
>
I would also include in UPDATE… but yeah, <3 BETWEEN and welcome this work.
> On May 13, 2024, at 7:40 AM, Patrick McFadin wrote:
>
> This is a great feature addition to CQL! I get asked about it from time to
> time but then people figure out a workaround. It will be great to just have
> it av
This is a great feature addition to CQL! I get asked about it from time to
time but then people figure out a workaround. It will be great to just have
it available.
And right on Simon! I think the only project I had as a high school senior
was figuring out how many parties I could go to and still
Hi everybody,
Just raising awareness that Simon is working on adding support for the
BETWEEN operator in WHERE clauses (SELECT and DELETE) in CASSANDRA-19604.
We plan to add support for it in conditions in a separate patch.
The patch is available.
As a side note, Simon chose to do his highschool
16 matches
Mail list logo
