My only slight concern with this approach is the additional memory pressure. Since 64yrs should be plenty at any moment in time, I wonder if it wouldn’t be better to represent these times as deltas from the nowInSec being used to process the query. So, long math would only be used to normalise the times to this nowInSec (from whatever is stored in the sstable) within a method, and ints would be stored in memtables and any objects used for processing.
This might admittedly be more work, but I don’t believe it should be too challenging - we can introduce a method deletionTime(int nowInSec) that returns a long value by adding nowInSec to the deletionTime, and make the underlying value private, refactoring call sites? > On 29 Sep 2022, at 09:37, Berenguer Blasi <berenguerbl...@gmail.com> wrote: > > Hi all, > > I have taken a stab in a PR you can find attached in the ticket. Mainly: > > - I have moved deletion times, gc and nowInSec timestamps to long. That > should get us past the 2038 limit. > > - TTL is maxed now to 68y. Think CQL API compatibility and a sort of a 'free' > guardrail. > > - A new NONE overflow policy is the default but everything is backwards > compatible by keeping the previous ones in place. Think upgrade scenarios or > apps relying on the previous behavior. > > - The new limit is around year 292,471,208,677 which sounds ok given the Sun > will start collapsing in 3 to 5 billion years :-) > > - Please feel free to drop by the ticket and take a look at the PR even if > it's cursory > > Thx in advance.
