-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Major - P3
-
None
-
Affects Version/s: None
-
Component/s: None
-
Labels:
-
Storage Execution
We have different table configurations for collections and indexes:
Collections:
// Setting this larger than 10m can hurt latencies and throughput degradation if this
// is the oplog. See SERVER-16247
ss << "memory_page_max=10m,";
// Choose a higher split percent, since most usage is append only. Allow some space
// for workloads where updates increase the size of documents.
ss << "split_pct=90,";
ss << "leaf_value_max=64MB,";
// Separate out a prefix and suffix in the default string. User configuration will override
// values in the prefix, but not values in the suffix. Page sizes are chosen so that index
// keys (up to 1024 bytes) will not overflow.
ss << "type=file,internal_page_max=16k,leaf_page_max=16k,";
It appears that the rationale for using a high split_pct is that it benefits append-only workloads, although 90 is the default, so presumably there is no difference between collections and indexes. Clustered collections are not necessarily append-only, but it seems like 90 is a reasonable default for both.
Raising "internal_page_max" from the default of 4k would reduce tree depth when there are larger keys because more keys can fit on each internal node, so raising this value could benefit clustered collections whose keys are moderately large.