In general, the more nodes and resources that are available, the better the potential query performance.
Distributed query processing uses the available memory and CPU resources of all nodes of the logical server.
The amount of improvement benefit depends on the type of query, the size of the query, and the current workload of the nodes in the logical server.
Note: If you change the properties of multiplex server, including the server name, hostname, and port, then you must wait at least two minutes after restarting the multiplex server for it to participate in a DQP eligible query. In the first two minutes after restarting the server, if a DQP eligible query is executed, then the server may not participate.
It is unlikely that any two runs of the same query result in exactly the same work distribution — as load levels change in the cluster, so does the load distribution. Distributed query performance is determined by the overall workload of the logical server at any given time. Similarly, in a single run of a query with a long processing time, the work distribution changes over the course of query execution as the load balance changes across worker nodes.
Note: The -iqmc and -iqtc switches allow different cache sizes for each node in a multiplex,
but this may have adverse affects. For example, if a node worker is configured with a much
smaller cache than the leader, hash joins on the leader will operate in a paging mode that
disallows parallelism.
A high-speed private interconnect is preferred for best distributed query performance, but not required. See the
Installation and Configuration Guide > Preparing for Installation > Planning Your Installation > Planning for Distributed Query Processing or High Availability. Note: Do not use the NOEXEC option to examine DQP performance. NOEXEC is not useful for troubleshooting DQP.