I would wonder if what you did was:

a) Ran the original code
b) Modified the code to unroll the loop
c) Ran the modified code and noticed it was faster

But really what happened was that between (a) and (c) was that the database cached the query, so it responded much faster than on the first call.

Why would that seem more likely?

Because the time it takes to call to a database is hugely (many orders of magnitude) longer than it should take to run through a loop to get the data from the response. Think of what is happening when you make that call to the database? First, you need to get a connection to the database, then send the query over that, then the database parses it, analyzes the query, scans the table, collects up the data from disk, encodes that data for transmission, sends it over the socket where it is decoded by the client (the Java) app.

Then you run a simple for loop to extract it.

The for loop shouldn’t be a factor in the timing.

Your first idea (using multiple connections to each get a piece of the data) might help and is possible. You’d just break up the query into sections. It might also make it run slower overall, but it would certainly be doing different work and might boost things.

Unrolling the loop should make no measurable difference.

That part of your code with string concatenation is odd – what are you doing there and why?

Using a cursor (which is essentially and generally what you’re doing when you’re iterating a ResultSet) is certainly not without overhead. The only way to avoid overhead would be if results were cached in memory.