>In my view, we should hide most of such configuration intricacies from users, and select an appropriate thread pool for each task ourselves. Will this be possible?
We already do this. We take decision internally on where to route the request. SoE, my answers below. >How did the striped pool show itself for transactional updates that involve 2 phase commit? Any benefits or degradation? Even better than for atomic - up to ~50% improvement. >Here we should decide what’s more important for us - throughout or latency. If to execute SQL queries in the striped pool using multiple partitioned threads then, for sure, it will affect latency of other operations that are sitting in the queue waiting for their time to be processed but, on the other hand, the overall throughput of the platform should be improved because the operations will be less halted all the time by synchronization needs. >VoltDB decided to go for with the throughput while our current architecture is mostly latency based. What do you mean by "using several partition threads"? I am pretty sure that if we do as you suggest we will have degradation here instead of boost: sql-query-put after: 77,344.83 before: 53,578.78 delta: 30.73% sql-query-put-offheap after 32,212.30 before 25,322.43 delta 21.39% --Yakov
