There were primarily two problems with this storage scheme that made the container non-scalable. Searching for the value of an attribute for an arbitrary row was performed linearly from the first record since the core of the container itself was simply just an array. They were stored per range, not per individual row or column, so that if a range of rows had identical set of attribute values over the entire range, that attribute set would be stored as a single record. whether or not a row has a manual height.The old attribute container was designed to store several different attributes altogether, namely, Also, in this article, I’ll only talk about row attribute storage, but the same argument also applies to the column attribute storage as well. Limitation of the old attribute storageīefore I talk about how the row attributes are stored in the new storage, I’d like to talk about the limitation of the old attribute storage, and why it was not adequate when the row limit was raised to 1 million rows. The CWS also makes several other changes in order to improve performance in general, though not related to the change in the row attribute storage.
What this CWS does change is the storage of row attributes to 1) improve performance of querying the attributes, and to 2) make extra information available that can be used to make the algorithm of various bits of operations more efficient. However, the upstream build will not see the increase of the row limit itself yet, as the upstream developers still consider that move premature due to two outstanding issues that are show stoppers for them. The role of this CWS is to upstream various pieces of performance optimization from Go-OO, that arose from the increase of the row limit from 65536 (64 thousand rows) to 1048576 (1 million rows). With the child work space (CWS) koheirowlimitperf being marked ready for QA, I believe this is a good time to talk about the change that the CWS will bring once it gets integrated.
0 kommentar(er)
