Lazy loading of primary keys in memory#60093
Conversation
|
This is an automated comment for commit 8d6e6d6 with description of existing statuses. It's updated for the latest CI running ❌ Click here to open a full report in a separate page Successful checks
|
…nsistent-formatting-of-explain-in-subqueries
…consistent-formatting-of-explain-in-subqueries
…nto lazy-primary-key-loading
|
Race probably introduced by this PR https://s3.amazonaws.com/clickhouse-test-reports/59460/0be66e95762ed82f971be3dc64e783fcb279abf3/stateless_tests__tsan__s3_storage_/stderr.log |
And it was even found by the CI in the last commit in this PR: https://s3.amazonaws.com/clickhouse-test-reports/60093/8d6e6d67ed8b529794ef9ef7585d60c446df2d57/stateless_tests__tsan__s3_storage_/stderr.log @alexey-milovidov, please don't forget to check CI failures before merging |
Changelog category (leave one):
Changelog entry (a user-readable short description of the changes that goes to CHANGELOG.md):
The tables' primary keys will be loaded in memory lazily on first access. This is controlled by the new MergeTree setting
primary_key_lazy_load, which is on by default. This provides several advantages: - it will not be loaded for tables that are not used; - if there is not enough memory, an exception will be thrown on first use instead of at server startup. This provides several disadvantages: - the latency of loading the primary key will be paid on the first query rather than before accepting connections; this theoretically may introduce a thundering-herd problem. This closes #11188.