Document separated thread pools in the remaining pages - #547
Open
PasinduOshada wants to merge 1 commit into
Open
Document separated thread pools in the remaining pages#547PasinduOshada wants to merge 1 commit into
PasinduOshada wants to merge 1 commit into
Conversation
Partially addresses questdb#229 configuration/shared-workers.md already documents the network, query and write pools in full, so this covers the pages the issue lists that still describe the old single shared pool. architecture/query-engine.md claimed "most tasks are handled by a shared worker pool", which stopped being true when the pools were separated. Describe the three pools and why the split matters: query execution has its own pool, so an ingestion burst does not starve readers of CPU. getting-started/capacity-planning.md discussed CPU cores without mentioning that cores are divided between pools, which is the setting to reach for when a workload is lopsided. Add a pool-to-setting table and read-heavy, ingestion-heavy and many-clients guidance, noting the pools oversubscribe the machine by default and that the default formula floors each pool at two threads. deployment/hetzner.md still recommended shared.worker.count, which no longer exists, and listed it as a memory setting rather than a threading one. The capacity planning and architecture URLs in the issue predate the docs restructure; these are the pages that content now lives in. The networking layer and data ingestion architecture pages no longer exist.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Partially addresses #229
configuration/shared-workers.mdalready documents the network, query and write pools in full, so nothing was needed there. This covers the other pages the issue lists, which still described the old single shared pool.What changed
architecture/query-engine.md— claimed "By default, most tasks are handled by a shared worker pool." That stopped being true when the pools were separated. Now describes the three pools and why the split matters: query execution has its own pool, so an ingestion burst does not starve readers of CPU.getting-started/capacity-planning.md— the CPU cores section linked to the shared workers guide but never said cores are divided between pools, which is the thing you actually tune when a workload is lopsided. Adds a pool-to-setting table plus read-heavy / ingestion-heavy / many-clients guidance, and notes the pools oversubscribe the machine by default rather than partitioning it.deployment/hetzner.md— recommendedshared.worker.count, which no longer exists, and filed it under "Memory settings" rather than threading. This was the last reference to the old property outside the changelog.A note on the issue's links
The capacity planning and architecture URLs in the issue predate the docs restructure.
operations/capacity-planningis nowgetting-started/capacity-planning, and the networking layer and data ingestion architecture pages no longer exist — their content sits inarchitecture/query-engine.mdandarchitecture/storage-engine.md. I've updated where that content actually lives; happy to go further if some of it belongs elsewhere.Notes
configuration/shared-workers.md(the default formula ismax(2, ...)), not invented.pg.worker.countin capacity planning alone — it is still valid, defaulting to0meaning "use the shared pool".