core/src/main/java/io/questdb/PropServerConfiguration.java:1920

• The assignment this.metrics is incorrect and will not compile, as PropServerConfiguration has no metrics field of type WorkerPoolConfiguration.Metrics. You should assign a valid Metrics enum value (e.g. Metrics.ENABLED or Metrics.DISABLED) or retrieve it from the server's metrics configuration. For example:

poolConfiguration.metrics = config.getMetricsConfiguration().isEnabled() ? Metrics.ENABLED : Metrics.DISABLED;

        poolConfiguration.metrics = this.metrics;

core/src/test/java/io/questdb/test/griffin/engine/functions/bool/WithinGeohashFunctionFactoryTest.java (1)

341-346: Duplicate of previous remark

The second expectation string has the same hard-coded workers: 2; please apply the same adjustment.

core/src/main/java/io/questdb/ServerMain.java (1)

428-432: FlushQueryCacheJob should be assigned to the query pool.

This job deals with query caching and belongs on the query pool rather than the network pool.

core/src/main/java/io/questdb/DefaultServerConfiguration.java (1)

152-171: Incomplete implementation of WorkerPoolConfiguration interface.

The DefaultWorkerPoolConfiguration class only implements getPoolName() and getWorkerCount(). Other interface methods may return default values which could affect worker affinity, sleep thresholds, and metric registration.

core/src/main/java/io/questdb/WorkerPoolManager.java (1)

128-135: Log messages should indicate pool type.

The log messages are ambiguous as they all use the same prefix. Include the pool type in the message to clearly differentiate in logs.

core/src/test/java/io/questdb/test/griffin/LatestByTest.java (1)

180-185: Hard-coding the expected worker count makes the test brittle

workers: 2 is embedded directly in the expected plan string. If the default sharedQueryWorkerCount is changed via configuration or future refactor, this assertion will fail for reasons unrelated to query logic. Consider deriving the worker count from the active configuration (e.g. SharedWorkerPool.getWorkerCount()) or asserting via a regex such as workers: \\d+.

core/src/test/java/io/questdb/test/griffin/engine/functions/bool/WithinGeohashFunctionFactoryTest.java (1)

283-288: Same brittleness as above – avoid hard-wiring workers: 2

For maintainability, assert against workers: \\d+ or build the string with the actual query-worker-pool size at runtime.

core/src/main/resources/io/questdb/site/conf/server.conf (1)

25-30: Consider clarifying the precedence behavior.

The configuration shows both specific pool configurations (lines 8, 14, 20) and the default configuration (line 26). It would be helpful to clarify in the documentation how these interact - does the default value only apply when specific pool values are not set?

Consider adding a comment explaining the precedence behavior:

-# Default number of worker threads in Network, Query and Write shared pools. Single value to configure all three pools sizes.
+# Default number of worker threads in Network, Query and Write shared pools. Single value to configure all three pools sizes.
+# This value is used when specific pool configurations (shared.network.worker.count, shared.query.worker.count, shared.write.worker.count) are not set.

core/src/main/java/io/questdb/DynamicPropServerConfiguration.java (2)

358-361: Add missing non-reloadable comment for consistency.

The method implementation is correct, but it's missing the "// nested object is kept non-reloadable" comment that appears in other similar methods like getNetworkWorkerPoolConfiguration() and getWalApplyPoolConfiguration().

 @Override
 public WorkerPoolConfiguration getQueryWorkerPoolConfiguration() {
+    // nested object is kept non-reloadable
     return serverConfig.get().getQueryWorkerPoolConfiguration();
 }

---

363-366: Add missing non-reloadable comment for consistency.

The method implementation is correct, but it's also missing the "// nested object is kept non-reloadable" comment for consistency with other similar methods.

 @Override
 public WorkerPoolConfiguration getWriteWorkerPoolConfiguration() {
+    // nested object is kept non-reloadable
     return serverConfig.get().getWriteWorkerPoolConfiguration();
 }

core/src/test/java/io/questdb/test/cutlass/pgwire/PGJobContextTest.java (4)

139-141: Consider using specific imports instead of wildcards for better code clarity.

While wildcard imports reduce verbosity, specific imports make it clearer which methods are being used and help avoid potential naming conflicts.

-import static io.questdb.test.tools.TestUtils.*;
-import static org.junit.Assert.*;
+import static io.questdb.test.tools.TestUtils.assertResultSet;
+import static org.junit.Assert.assertNotNull;

---

3812-3874: Fix comment inconsistency and excellent test isolation.

The implementation correctly sets sharedQueryWorkerCount = 2 and properly cleans up in the finally block. However, the comment mentions "Set to 1" while actually setting to 2.

-        sharedQueryWorkerCount = 2; // Set to 1 to enable parallel query plans
+        sharedQueryWorkerCount = 2; // Set to 2 to enable parallel query plans

The expected query plans correctly reflect the parallel execution with "Async Filter workers: 2", and the try-finally pattern ensures proper test isolation.

---

3892-3923: Fix comment inconsistency.

Same issue as the previous method - the comment mentions "Set to 1" while actually setting to 2.

-        sharedQueryWorkerCount = 2; // Set to 1 to enable parallel query plans
+        sharedQueryWorkerCount = 2; // Set to 2 to enable parallel query plans

Good descriptive cleanup comment and correct expected query plan with "Async Filter workers: 2".

---

3804-3881: Fix comment inconsistency.

Same comment issue as the previous methods - mentions "Set to 1" while setting to 2.

-        sharedQueryWorkerCount = 2; // Set to 1 to enable parallel query plans
+        sharedQueryWorkerCount = 2; // Set to 2 to enable parallel query plans

The test comprehensively covers multiple scenarios and correctly expects "Async Filter workers: 2" in the query plan.

core/src/main/java/io/questdb/PropServerConfiguration.java (2)

1919-1944: Good refactoring to reduce code duplication.

The helper method effectively consolidates the shared thread pool configuration logic. Consider using a builder pattern or configuration object in the future if more parameters are added, as the method signature is already quite long.

---

1913-1916: Consider aligning field name with method name.

The method getNetworkWorkerPoolConfiguration() returns lineTcpIOWorkerPoolConfiguration. For consistency, consider renaming the field to lineTcpNetworkWorkerPoolConfiguration or keeping the method name as getIOWorkerPoolConfiguration().