Skip to content

Document separated thread pools in the remaining pages - #547

Open
PasinduOshada wants to merge 1 commit into
questdb:mainfrom
PasinduOshada:docs/separated-thread-pools-remaining-pages
Open

Document separated thread pools in the remaining pages#547
PasinduOshada wants to merge 1 commit into
questdb:mainfrom
PasinduOshada:docs/separated-thread-pools-remaining-pages

Conversation

@PasinduOshada

Copy link
Copy Markdown

Partially addresses #229

configuration/shared-workers.md already 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 — recommended shared.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-planning is now getting-started/capacity-planning, and the networking layer and data ingestion architecture pages no longer exist — their content sits in architecture/query-engine.md and architecture/storage-engine.md. I've updated where that content actually lives; happy to go further if some of it belongs elsewhere.

Notes

  • Pool descriptions and the two-thread floor are taken from configuration/shared-workers.md (the default formula is max(2, ...)), not invented.
  • Left pg.worker.count in capacity planning alone — it is still valid, defaulting to 0 meaning "use the shared pool".

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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant