## 3.2.5  Controlling Parallel Execution of SQL Statements
You can apply ini file settings to control the two thread pools SqlExecutor and JobExecutor that control the parallelism of statement execution.
##  Caution
The settings described here should only be modified when other tuning techniques like remodeling, repartitioning, and query tuning have been applied. Modifying the parallelism settings requires a thorough understanding of the actual workload since they have impact on the overall system behavior. Modify the settings iteratively by testing each adjustment. For more information, see Understand your Workload .
On systems with highly concurrent workload, too much parallelism of single statements may lead to suboptimal performance. Note also that partitioning tables influences the degree of parallelism for statement execution; in general, adding partitions tends to increase parallelism. You can use the parameters described in this section to adjust the CPU utilization in the system.
Two thread pools control the parallelism of the statement execution. Generally, target thread numbers applied to these pools are soft limits, meaning that additional available threads can be used if necessary and deleted when no longer required:
- SqlExecutor
This thread pool handles incoming client requests and executes simple statements. For each statement execution, an SqlExecutor thread from a thread pool processes the statement. For simple OLTP-like statements against column store as well as for most statements against row store, this will be the only type of thread involved. With OLTP we mean short running statements that consume relatively little resources, however, even OLTP-systems like SAP Business Suite may generate complex statements.
## · JobExecutor
The JobExecutor is a job dispatching subsystem. Almost all remaining parallel tasks are dispatched to the JobExecutor and its associated JobWorker threads.
In addition to OLAP workload the JobExecutor also executes operations like table updates, backups, memory garbage collection, and savepoint writes.
You can set a limit for both SqlExecutor and JobExecutor to define the maximum number of threads. You can use this for example on a system where OLAP workload would normally consume too many CPU resources to apply a maximum value to the JobExecutor to reserve resources for OLTP workload.
##  Caution
Lowering the value of these parameters can have a drastic effect on the parallel processing of the servers and reduce the performance of the overall system. Adapt with caution by iteratively making modifications and testing. For more information, see Understand your Workload and SAP Note 2222250 - FAQ SAP HANA Workload Management which contains more details of the workload configuration parameters.
A further option to manage statement execution is to apply a limit to an individual user profile for all statements in the current connection using 'THREADLIMIT' parameter. This option is described in Setting User Parameters .
## Parameters for SqlExecutor
The following SqlExecutor parameters are in the sql section of the indexserver.ini file.
sql_executors - sets a soft limit on the target number of logical cores for the SqlExecutor pool.
- This parameter sets the target number of threads that are immediately available to accept incoming requests. Additional threads will be created if needed and deleted if not needed any more.
- The parameter is initially not set (0); the default value is the number of logical cores in a system. As each thread allocates a particular amount of main memory for the stack, reducing the value of this parameter can help to avoid memory footprint.
max_sql_executors - sets a hard limit on the maximum number of logical cores that can be used.
- In normal operation new threads are created to handle incoming requests. If a limit is applied here, SAP HANA will reject new incoming requests with an error message if the limit is exceeded.
- The parameter is initially not set (0) so no limit is applied.
##  Caution
SAP HANA will not accept new incoming requests if the limit is exceeded. Use this parameter with extreme care.
## Parameters for JobExecutor
The following JobExecutor parameters are in the execution section of the global.ini or indexserver.ini .
max_concurrency - sets the target number of logical cores for the JobExecutor pool.
- This parameter sets the size of the thread pool used by the JobExecutor used to parallelize execution of database operations. Additional threads will be created if needed and deleted if not needed any more. You can use this to limit resources available for JobExecutor threads, thereby saving capacity for SqlExecutors.
- The parameter is initially not set (0); the default value is the number of logical cores in a system. Especially on systems with at least 8 sockets consider setting this parameter to a reasonable value between the number of logical cores per CPU up to the overall number of logical cores in the system. In a system that supports tenant databases, a reasonable value is the number of cores divided by the number of tenant databases.
max_concurrency_hint - limits the number of logical cores for job workers even if more active job workers would be available.
- This parameter defines the number of jobs to create for an individual parallelized operation. The JobExecutor proposes the number of jobs to create for parallel processing based on the recent load on the system. Multiple parallelization steps may result in far more jobs being created for a statement (and hence higher concurrency) than this parameter.
- The default is 0 (no limit is applied but the hint value is never greater than the value for max_concurrency ). On large systems (that is more than 4 sockets) setting this parameter to the number of logical cores of one socket may result in better performance but testing is necessary to confirm this.
default_statement_concurrency_limit - restricts the actual degree of parallel execution per connection within a statement.
- This parameter controls the maximum overall parallelism for a single database request. Set this to a reasonable value (a number of logical cores) between 1 and max_concurrency but greater or equal to the value set for max_concurrency_hint .
- The default setting is 0; no limit is applied. Note, however, that a new default value for this parameter may also be set during installation using the SAP HANA database lifecycle manager (HDBLCM) tool. In this case, a limit may already be in force. See also SAP Note 3011356 - Default Value of global.ini [execution] default_statement_concurrency_limit Changed.
## Related Information
Understand your Workload
Example Workload Management Scenarios Setting User Parameters for Workload
SAP Note 2222250
SAP Note 3011356