Tuning Tuple Mover Pool Settings

Scenario 1

During heavy load operations, you occasionally notice spikes in the number of ROS containers. You would like the Tuple Mover to perform mergeout more aggressively to consolidate ROS containers, and avoid ROS pushback.

Solution

Use ALTER RESOURCE POOL to increase the setting of MAXCONCURRENCY in the TM resource pools. This setting determines how many threads are available for mergeout. By default , this parameter is set to 7. Vertica allocates half the threads to active partitions, and the remaining half to active and inactive partitions as needed. If MAXCONCURRENCY is set to an uneven integer, Vertica rounds up to favor active partitions.

For example, if you increase MAXCONCURRENCY to 9, then Vertica allocates five threads exclusively to active partitions, and allocates the remaining four threads to active and inactive partitions.

Scenario 2

You have a secondary subcluster that runs only analytic queries. By default, each subcluster has a built-in TM resource pool for tuple mover operations that uses 3 gigabytes of memory. Secondary subclusters cannot run tuple mover operations, so you want to reallocate those 3 gigabytes to use for analytic queries.

Solution

Use ALTER RESOURCE POOL to override the global TM resource pool for the secondary subcluster, and set its MEMORYSIZE to 0. This allows you to use the memory consumed by the global TM pool for use running analytic queries.