[
https://issues.apache.org/jira/browse/CASSANDRA-20761?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18006715#comment-18006715
]
Stefan Miklosovic edited comment on CASSANDRA-20761 at 7/15/25 11:36 AM:
-------------------------------------------------------------------------
1) The current code errors out then MVs are attempted to be truncated directly
as it says you need to truncate the underlying table so this is a non-issue? I
think they are just taken care of automatically. It is also not possible to
truncate an index. Where do you find it problematic?
I think it is OK to just loop over all tables in a keyspace and truncate one by
one. Each truncation will check if all nodes are up (1) and fails when they are
not and this would be done per table.
However, what I think might be a little bit problematic is that if there is a
keyspace consisting of 100 tables and you go to truncate them all, the
cumulative time it takes to truncate all of them might be bigger than request
timeout. So a user would see that his request timeouted just because there was
too many tables to truncate. This does not happen (at least not too often) if
there is just one table to truncate.
There might be some mechanism how to submit truncation of a table so it would
return practically immediately and a user would have a way to consult what
tables are to be truncated yet (e.g. via a virtual table?).
This mechanism might be in place only in case we go to truncate more than one
table as the result of truncating a keyspace consisting of multiple tables. If
a user truncates one table specifically, then the current behavior would stay
and it would truncate in a "blocking" manner.
(1)
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/StorageProxy.java#L2998
was (Author: smiklosovic):
1) The current code errors out then MVs are attempted to be truncated directly
as it says you need to truncate the underlying table so this is a non-issue? I
think they are just taken care of automatically. It is also not possible to
truncate an index. Where do you find it problematic?
I think it is OK to just loop over all tables in a keyspace and truncate one by
one. Each truncation will check if all nodes are up (1) and fails when they are
not and this would be done per table.
However, what I think might be a little bit problematic is that if there is a
keyspace consisting of 100 tables and you go to truncate them all, the
cumulative time it takes to truncate all of them might be bigger than request
timeout. So a user would see that his request timeouted just because there was
too many tables to truncate. This does not happen (at least not too often) if
there is just one table to truncate.
There might be some mechanism how to submit truncation of a table so it would
return practically immediately and a user would have a way to consult what
tables are to be truncated yet (e.g. via a virtual table?).
(1)
https://github.com/apache/cassandra/blob/trunk/src/java/org/apache/cassandra/service/StorageProxy.java#L2998
> Support TRUNCATE <keyspace> to truncate all tables in it
> --------------------------------------------------------
>
> Key: CASSANDRA-20761
> URL: https://issues.apache.org/jira/browse/CASSANDRA-20761
> Project: Apache Cassandra
> Issue Type: New Feature
> Components: CQL/Semantics, CQL/Syntax
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
> Priority: Normal
> Fix For: 5.x
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If I want to truncate whole keyspace by one command, now I can not do that as
> I need to enumerate all tables from that keyspace and truncate one by one.
> It might be probably possible to do
> {code}
> TRUNCATE keyspace_name
> {code}
> which would internally iterate over all tables and truncate them all so user
> is saved from doing that.
> However, I think that the usage of
> {code}
> TRUNCATE keyspace_name
> {code}
> is a little bit risky because, for example, users might think that they are
> using keyspace already by USE statement so "keyspace_name" is actually a
> table name. If there is a keyspace of such name then it would truncate all
> tables in it.
> It would be probably better to have a new statement like
> {code}
> TRUNCATE KEYSPACE abc;
> {code}
> That way, it is pretty obvious what we want to truncate.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
