Во-первых, «огромные данные» для пользователей базы данных составляют [по меньшей мере] гигабайты, и в этом случае я подозреваю, что ваши проблемы будут заключаться в том, чтобы считывать такие объемы в память ваших процессов и объединять их там. Как вы думаете, почему однопоточное выделение будет узким местом?
Если бы узким местом было получение данных с диска, то одновременное извлечение данных с одного диска несколькими потоками не обязательно было бы быстрее, а может даже медленнее. Но если бы вы могли распределить данные по отдельным дискам, отдельные потоки были бы быстрее. Если, используя SSD, вы не думаете, что диски будут предметом спора, мы можем посмотреть в другом месте.
Если бы узким местом была пропускная способность сети, опять-таки, несколько потоков не поместили бы больше данных через канал быстрее. Вы даже можете извлечь выгоду из выгрузки данных в плоский файл, сжатия и передачи этого.
Если выборка сортируется или поступает из хеш-соединения, вы можете использовать память более эффективно с одним потоком. Несколько сеансов должны были бы совместно использовать память машины.
Если обработка процессора интенсивна, то могут помочь несколько потоков. Это может быть так же просто, как иметь несколько соединений из Java, каждое из которых получает различный фрагмент данных (например, A-K и L-Z), но это будет очень сильно зависеть от SELECT.
Я согласен с dpbradley, что вы должны сначала определить узкое место. Если у вас есть данные и вы выбрали, это должно быть достаточно просто, чтобы определить, сколько времени это займет (как на локальной машине, так и через сеть), и трассировка будет необходимой отправной точкой, чтобы действительно понять, как ее можно ускорить. .