[ 
https://issues.apache.org/jira/browse/CASSANDRA-11522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15241105#comment-15241105
 ] 

Paulo Motta commented on CASSANDRA-11522:
-----------------------------------------

I just noticed that CASSANDRA-10876 effectively removed this protection for 
single partition batches, given they do not have the same concerns as 
multi-partition batches (as discussed on CASSANDRA-8011). So I'm not sure we 
should introduce this limitation to single inserts.

> batch_size_fail_threshold_in_kb shouldn't only apply to batch
> -------------------------------------------------------------
>
>                 Key: CASSANDRA-11522
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11522
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Sylvain Lebresne
>            Assignee: Giampaolo
>            Priority: Minor
>              Labels: lhf
>
> I can buy that C* is not good at dealing with large (in bytes) inserts and 
> that it makes sense to provide a user configurable protection against inserts 
> larger than a certain size, but it doesn't make sense to limit this to 
> batches. It's absolutely possible to insert a single very large row and 
> internally a batch with a single statement is exactly the same than a single 
> similar insert, so rejecting the former and not the later is confusing and 
> well, wrong.
> Note that I get that batches are more likely to get big and that's where the 
> protection is most often useful, but limiting the option to batch is still 
> less useful (it's a hole in the protection) and it's going to confuse users 
> in thinking that batches to a single partition are different from single 
> inserts.
> Of course that also mean that we should rename that option to 
> {{write_size_fail_threshold_in_kb}}. Which means we probably want to add this 
> new option and just deprecate {{batch_size_fail_threshold_in_kb}} for now 
> (with removal in 4.0).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to