[
https://issues.apache.org/jira/browse/PHOENIX-3612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16030576#comment-16030576
]
Thomas D'Silva commented on PHOENIX-3612:
-----------------------------------------
[~jamestaylor]
We currently check the size of the {{Map<TableRef,
Map<ImmutableBytesPtr,RowMutationState>> mutations}} map in the MutationState
constructor and throw an exception if it exceeds the
{{QueryServices.MAX_MUTATION_SIZE_ATTRIB}} limit, so we don't have the
{{List<Mutation>}} at this point, should we estimate the size based on
{{RowMutationState}} which has the column values ?
Should I keep the existing config and add a new one to maintain b/w
compatibility? (and use the lower of the byte based and row count limit)
> Make tracking of max allowed number of mutations bytes based instead of row
> based
> ---------------------------------------------------------------------------------
>
> Key: PHOENIX-3612
> URL: https://issues.apache.org/jira/browse/PHOENIX-3612
> Project: Phoenix
> Issue Type: Bug
> Reporter: James Taylor
> Assignee: Thomas D'Silva
> Fix For: 4.11.0
>
>
> Some remaining work related to PHOENIX-541 to track the byte-size of all
> mutations being buffered instead of the number of rows:
> - Make similar changes QueryServices.MAX_MUTATION_SIZE_ATTRIB - making it
> byte-based instead of row-count-based. Usage of this config parameter would
> be isolated to MutationState, I believe. We should be able to come up with an
> accurate size based on the underlying Mutation and/or Delete info we store in
> PRowImpl.
> - Have a reasonable (smaller) default for the new
> QueryServices.MAX_MUTATION_SIZE_BYTES_ATTRIB
> This is essentially a guard on the memory usage. It could potentially
> leverage our MemoryManager.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
