[
https://issues.apache.org/jira/browse/CASSANDRA-16844?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17554088#comment-17554088
]
Josh McKenzie edited comment on CASSANDRA-16844 at 6/14/22 1:02 PM:
--------------------------------------------------------------------
{quote}it's all of the columns after CASSANDRA-16976, and a way to preserve the
contributions already committed would be to leave them in trunk,
{quote}
I'm -1 on cutting a major for any number of mandatory new columns in a single
tool's output. (edit: i.e. just make them optional via a feature flag)
{quote}The question is only whether or not we should break any given API, and
in this case I think the answer is clearly no - again, whether or not we have
bumped the major version.
{quote}
^ This. We don't have a consensus on cutting 5.0 based on what's been proposed,
and we should revert changes that force a major if we haven't had that
discussion yet.
We should take this to dev@.
was (Author: jmckenzie):
bq. it's all of the columns after CASSANDRA-16976, and a way to preserve the
contributions already committed would be to leave them in trunk,
I'm -1 on cutting a major for any number of mandatory new columns in a single
tool's output.
bq. The question is only whether or not we should break any given API, and in
this case I think the answer is clearly no - again, whether or not we have
bumped the major version.
^ This. We don't have a consensus on cutting 5.0 based on what's been proposed,
and we should revert changes that force a major if we haven't had that
discussion yet.
We should take this to dev@.
> Add number of sstables in a compaction to compactionstats output
> ----------------------------------------------------------------
>
> Key: CASSANDRA-16844
> URL: https://issues.apache.org/jira/browse/CASSANDRA-16844
> Project: Cassandra
> Issue Type: Improvement
> Components: Tool/nodetool
> Reporter: Brendan Cicchi
> Assignee: Brandon Williams
> Priority: Normal
> Fix For: 4.1, 4.1-alpha1
>
>
> It would be helpful to know at a glance how many sstables are involved in any
> running compactions. While this information can certainly be collected now, a
> user has to grab it from the debug logs. I think it would be helpful for some
> use cases to have this information straight from {{nodetool compactionstats}}
> and then if the actual sstables involved in the compactions are desired, dive
> into the debug.log for that. I think it would also be good to have this
> information in the output of {{nodetool compactionhistory}}.
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
