Re: max_compaction_threshold removed - bad move
On Wed, Jan 9, 2013 at 9:21 AM, Radim Kolar h...@filez.com wrote: removing max_compaction_threshold in 1.2 was bad move, keeping it low helps compaction throughput because it lowers number of disk seeks. :(
Re: max_compaction_threshold removed - bad move
:( Seems like a good thing to have, i can figure at least one degenerate scenario where having that helps. The first being a currupt sstable... compaction will never be able to remove it and then each compaction will likely try to comact it again... and fail. On Wed, Jan 9, 2013 at 10:35 AM, Brandon Williams dri...@gmail.com wrote: On Wed, Jan 9, 2013 at 9:21 AM, Radim Kolar h...@filez.com wrote: removing max_compaction_threshold in 1.2 was bad move, keeping it low helps compaction throughput because it lowers number of disk seeks. :(
Re: max_compaction_threshold removed - bad move
On Wed, Jan 9, 2013 at 9:40 AM, Edward Capriolo edlinuxg...@gmail.com wrote: :( Seems like a good thing to have, i can figure at least one degenerate scenario where having that helps. The first being a currupt sstable... compaction will never be able to remove it and then each compaction will likely try to comact it again... and fail. They will get blacklisted: https://issues.apache.org/jira/browse/CASSANDRA-2261
Re: max_compaction_threshold removed - bad move
Yikes. Please would be nice.. Also, Sylvian already said they would update the documentation. As a developer, who hasn't forgotten to update documentation? On 1/9/13 8:07 AM, Radim Kolar h...@filez.com wrote: if this was renamed then update your documentation: http://www.datastax.com/docs/1.2/configuration/storage_configuration Southfield Public School students safely access the tech tools they need on and off campus with the Barracuda Web Filter. Quick installation and easy to use- try the Barracuda Web Filter free for 30 days: http://on.fb.me/Vj6JBd
Re: max_compaction_threshold removed - bad move
On Wed, Jan 9, 2013 at 5:04 PM, Edward Capriolo edlinuxg...@gmail.comwrote: Was the change well accounted for in the changes.TXT or the readme.txt? The news file says: CQL3 is now considered final in this release. Compared to the beta version that is part of 1.1, this final version has a few additions (collections), but also some (incompatible) changes in the syntax for the options of the create/alter keyspace/table statements. (...) Please refer to the CQL3 documentation for details That last sentence refers to http://cassandra.apache.org/doc/cql3/CQL.htmland yes, that should be in the news file but that same url was pointing to the 1.1 CQL3 doc before 1.2.0 was release so I didn't wanted to list it in the news file for the betas and rcs and I forgot to add back the link to that news file for the final, my bad (I'm sorry and I will add the link to the NEWS file for the next release). And of course having forgotten to update the max_threshold thing in said reference doc was infortunate but that's fixed now. Now I know you are not happy with us having made breaking changes between CQL3 beta in 1.1 and CQL3 final in 1.2. I'm sorry we did, but I do am happy with the coherence of the language we have in that final so I think that was probably worth it in the end. I do want to stress that the goal was to have a CQL3 final for which we won't do breaking changes for the forseable future. // Note that isCompact means here that no componet of the comparator correspond to the column names // defined in the CREATE TABLE QUERY. This is not exactly equivalent to the 'WITH COMPACT STORAGE' // option when creating a table in that static CF without a composite type will have isCompact == false // even though one must use 'WITH COMPACT STORAGE' to declare them. Confused Granted that is not the cleanest thing ever and we could probably rename that isCompact variable but you do realize that is just an implementation detail that have no impact whatsoever on users. If you want to complain about bad names in the code, start with the class implementing keyspaces being called Table. -- Sylvain
Re: max_compaction_threshold removed - bad move
If you want to complain about bad names in the code, start with the class implementing keyspaces being called Table. OMG that is terrible! We should only be wrongfully calling a column family a table :) (In hbase tables are actually a collection of column familes right so that is probably where that came from) On Wed, Jan 9, 2013 at 11:25 AM, Sylvain Lebresne sylv...@datastax.comwrote: On Wed, Jan 9, 2013 at 5:04 PM, Edward Capriolo edlinuxg...@gmail.com wrote: Was the change well accounted for in the changes.TXT or the readme.txt? The news file says: CQL3 is now considered final in this release. Compared to the beta version that is part of 1.1, this final version has a few additions (collections), but also some (incompatible) changes in the syntax for the options of the create/alter keyspace/table statements. (...) Please refer to the CQL3 documentation for details That last sentence refers to http://cassandra.apache.org/doc/cql3/CQL.htmland yes, that should be in the news file but that same url was pointing to the 1.1 CQL3 doc before 1.2.0 was release so I didn't wanted to list it in the news file for the betas and rcs and I forgot to add back the link to that news file for the final, my bad (I'm sorry and I will add the link to the NEWS file for the next release). And of course having forgotten to update the max_threshold thing in said reference doc was infortunate but that's fixed now. Now I know you are not happy with us having made breaking changes between CQL3 beta in 1.1 and CQL3 final in 1.2. I'm sorry we did, but I do am happy with the coherence of the language we have in that final so I think that was probably worth it in the end. I do want to stress that the goal was to have a CQL3 final for which we won't do breaking changes for the forseable future. // Note that isCompact means here that no componet of the comparator correspond to the column names // defined in the CREATE TABLE QUERY. This is not exactly equivalent to the 'WITH COMPACT STORAGE' // option when creating a table in that static CF without a composite type will have isCompact == false // even though one must use 'WITH COMPACT STORAGE' to declare them. Confused Granted that is not the cleanest thing ever and we could probably rename that isCompact variable but you do realize that is just an implementation detail that have no impact whatsoever on users. If you want to complain about bad names in the code, start with the class implementing keyspaces being called Table. -- Sylvain
Re: max_compaction_threshold removed - bad move
On Wed, Jan 9, 2013 at 5:30 PM, Edward Capriolo edlinuxg...@gmail.comwrote: If you want to complain about bad names in the code, start with the class implementing keyspaces being called Table. OMG that is terrible! I know!!! -- Sylvain
