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, in many cases, because the width of the range is uncountable for some types).
Setting aside whether or not this construct is worth adding (I suspect a lot of binding votes would say it’s not), the thread focuses on BETWEEN operator, and there’s no reason we should pollute the conversation of “add a missing SQL operator that basically maps to existing functionality” with creation of a brand new form of update that definitely doesn’t map to any existing concepts. > On May 14, 2024, at 10:05 AM, Jon Haddad <j...@jonhaddad.com> wrote: > > 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 > rows returned. We've also merged in Vector search which has O(N) overhead > with the number of SSTables. We're still fundamentally looking at, in most > cases, a limited number of SSTables and some merging of values. > > Write updates are essentially a timestamped mask, potentially overlapping, > and I suspect potentially resolvable during compaction by propagating the > values. They could be eliminated or narrowed based on how they've propagated > by using the timestamp metadata on the SSTable. > > 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. We haven't even moved this past an idea. > > I think it would solve a massive problem for a lot of people and is 100% > worth considering. Thanks Patrick and David for raising this. > > Jon > > > > On Tue, May 14, 2024 at 9:48 AM Bowen Song via dev <dev@cassandra.apache.org > <mailto:dev@cassandra.apache.org>> wrote: >> 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 simpler, because the "value" is the same tombstone >> marker, and it also is guaranteed to expire and disappear eventually, so the >> performance impact of dealing with them at read and compaction time doesn't >> suffer in the long term. >> >> >> On 14/05/2024 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 <j...@jonhaddad.com >>> <mailto:j...@jonhaddad.com>> a écrit : >>>> 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 <ble...@apache.org >>>> <mailto:ble...@apache.org>> wrote: >>>>> 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 <dcapw...@apple.com >>>>> <mailto:dcapw...@apple.com>> a écrit : >>>>>> I would also include in UPDATE… but yeah, <3 BETWEEN and welcome this >>>>>> work. >>>>>> >>>>>>> On May 13, 2024, at 7:40 AM, Patrick McFadin <pmcfa...@gmail.com >>>>>>> <mailto:pmcfa...@gmail.com>> 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 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 >>>>>>> maintain a passing grade. Thanks for your work here. >>>>>>> >>>>>>> Patrick >>>>>>> >>>>>>> On Mon, May 13, 2024 at 1:35 AM Benjamin Lerer <ble...@apache.org >>>>>>> <mailto:ble...@apache.org>> wrote: >>>>>>>> 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 senior project >>>>>>>> contributing to Apache Cassandra. This patch is his first contribution >>>>>>>> for his senior project (his second feature contribution to Apache >>>>>>>> Cassandra). >>>>>>>> >>>>>>>> >>>>>>
