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
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.