Re: secondary index table - tombstones surviving compactions

2018-05-31 Thread Roman Bielik
More details there. > > Thanks for reporting! > Jordan > > > On Wed, May 23, 2018 at 12:06 AM, Roman Bielik < > roman.bie...@openmindnetworks.com> wrote: > > > Hi, > > > > I apologise for a late response I wanted to run some further tests so I > can >

Re: secondary index table - tombstones surviving compactions

2018-05-23 Thread Roman Bielik
move > the > > tombstone (it would have to fully materialize every record in the > > compaction, which is too expensive). > > > > In general it is an antipattern in Cassandra to write to a given > partition > > indefinitely for this and other reasons. > > &g

secondary index table - tombstones surviving compactions

2018-05-18 Thread Roman Bielik
Hi, I have a Cassandra 3.11 table (with compact storage) and using secondary indices with rather unique data stored in the indexed columns. There are many inserts and deletes, so in order to avoid tombstones piling up I'm re-using primary keys from a pool (which works fine). I'm aware that this

Create table with ID - Question

2016-09-28 Thread Roman Bielik
Hi, in CQL it is possible to create a table with explicit ID: CREATE TABLE ... WITH ID='xyz'. Is something like this possible via Thrift interface? There is an int32 "id" field in CfDef, but it has no effect on the table ID. My problem is, that concurrent create table (add_column_family)