Re: performance penalty of add column in CQL3

2017-07-25 Thread Boris Iordanov
Thank you! Boris > On Jul 25, 2017, at 7:44 PM, kurt greaves wrote: > > If by "offline" you mean with no reads going to the nodes, then yes that > would be a potentially safe time to do it, but it's still not advised. You > should avoid doing any ALTERs on versions of 3

Re: performance penalty of add column in CQL3

2017-07-25 Thread kurt greaves
If by "offline" you mean with no reads going to the nodes, then yes that would be a *potentially *safe time to do it, but it's still not advised. You should avoid doing any ALTERs on versions of 3 less than 3.0.14 or 3.11 if possible. Adding/dropping a column does not require a re-write of the

Re: performance penalty of add column in CQL3

2017-07-25 Thread Boris Iordanov
No, I hadn’t, thanks much for pointing it out! The take away for me is then that such an update should be done offline. In that case, a schema change would be safe and relatively efficient (wouldn’t take hours). If that assumption is wrong, could anybody let me know? Thanks much, Boris > On

Re: performance penalty of add column in CQL3

2017-07-25 Thread Fay Hou [Storage Service] ­
are you aware this ticket? https://issues.apache.org/jira/browse/CASSANDRA-13004 On Tue, Jul 25, 2017 at 1:23 PM, Boris Iordanov wrote: > Hi, > > Is "alter table t add column..." an expensive operation? For example, if > it's something to be triggered at an admin level

performance penalty of add column in CQL3

2017-07-25 Thread Boris Iordanov
Hi, Is "alter table t add column..." an expensive operation? For example, if it's something to be triggered at an admin level of an application (i.e. not frequently), is it ok? It won’t trigger rewriting all the data, right? My goal is not to have super wide tables, I know that’s not the