I am trying to update a table-level TTL from unlimited to some determined value.
I have a statement syntax (which is pretty straight-forward): alter table <table_name> with default_time_to_live = <your_time_in_seconds>
I have tested this on my local (with existing records) and it works as advertized.
What I have a concern about is when I run this statement in PROD (where there are a lot of records), this statement might take a long time to run - long enough for my request to time out.
The reason I suspect that is because select count(*) timed out on the table in question.
It did run when I set the request timeout to 60 sec.
I was wondering what the default behavior is with respect to timed out requests: does it mean that the server is still processing the request and I just will not be able to see its completion or does it mean that the server gave up on the request (cancelled / rolled back, etc.)
How would that work with the alter statement above.
Note that setting a TTL is a change in schema (and therefore is not affected by the dataset size), while
SELECT count(*) is a query that reads all data internally (and gets affected by the amount of data in the database).
Because this is a prod question, I would like @mihnea to confirm this as well - the change TTL once fired should continue to execute and not be cancelled.
As @karthik mentioned, the alter table operation to change the TTL of a table shouldn’t depend on data set size. It is a metadata change operation that does not depend on the number of rows in the table.
However, it does depend on the number of internal shards (tablets) a table has. So you may still want to run the operation with a little bit higher timeout just in case. But note that even if the client times out because of smaller default timeout, the operation will proceed on the server side till it is applied to all tablets of the table.
If you are running from cqlsh, you could do something like:
% cqlsh --request-timeout=60
and issue the alter statement. Default cqlsh timeout is 10 seconds.