On top of that, the page breaks themselves are actually single-row attributes it made little sense to store them in a container that was range-based. Because of this, storing that together with the hidden and filtered attributes unnecessarily increased the partition count, which in turn would slow down the query speed of all three attributes.Įven more problematic was the automatic page break attributes because the automatic page breaks always need to be set for the entire sheet, increasing the row limit significantly raised the partition count. First, the attributes stored together in this container had different distribution patterns, which caused over-partitioning of the container and unnecessarily slowed down the queries of all stored attributes.įor instance, the hidden and filtered attributes are distributed in a very similar manner, but the manual height attribute is not necessarily distributed in a manner similar to these attributes. 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)
