Details
-
Bug
-
Resolution: Fixed
-
Critical
-
4.0.0
-
Security Level: Public
-
Untriaged
-
Unknown
Description
We found that the parallel operator caused a huge performance hit on because it would always spawn off goroutines and copy the execution plan based on the number of cpu's. This is an issue because sometimes this copying overhead is overkill.
An example is when we do a single key-value lookup. We only need to fetch one key, but on a 48 core box we create 48 go routines to get that single key. This creates a large amount of garbage and wastes cpu cycle.
Gerald recently introduced a change to allow the max-parallelism to be set on a per query basis and the performance team saw a huge performance boost when setting max-parallelism to 1.
Setting this on each individual query however is not something we want uses to have to do and we need to come up with a reasonable default based on the particular query we are running.
Users should only have to set the max-parallelism parameter if they want to override this default.