You’re right it’s not stored in metadata now. Adding this to metadata isn’t hard, it’s just hard to do it right where it’s useful to people with other data models (besides yours) so it can make it upstream (if that’s your goal). In particular the worst possible case is a table with no clustering key and a single non-partition key column. In that case storing these extra two long time stamps may be 2-3x more storage than without, which would be a huge regression, so you’d have to have a way to turn that feature off.
Worth mentioning that there are ways to do this without altering Cassandra - consider using static columns that represent the min timestamp and max timestamp. Create them both as ints or longs and write them on all inserts/updates (as part of a batch, if needed). The only thing you’ll have to do is find a way for “min timestamp” to work - you can set the min time stamp column with an explicit “using timestamp” timestamp = 2^31-NOW, so that future writes won’t overwrite those values. That gives you a first write win behavior for that column, which gives you an effective min timestamp for the partition as a whole. -- Jeff Jirsa > On Jan 13, 2018, at 4:58 AM, Arthur Kushka <arhel...@gmail.com> wrote: > > Hi folks, > > Currently, I working on custom CQL operator that should return the max > timestamp for some partition. > > I don't think that scanning of partition for that kind of data is a nice > idea. Instead of it, I thinking about adding a metadata to the partition. I > want to store minTimestamp and maxTimestamp for every partition as it > already done in Memtable`s. That timestamps will be updated on each > mutation operation, that is quite cheap in comparison to full scan. > > I quite new to Cassandra codebase and want to get some critics and ideas, > maybe that kind of data already stored somewhere or you have better ideas. > Is my assumption right? > > Best, > Artur --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
