Message-ID: <gh-pgjdbc-pgjdbc-2325-c4143405934@github.com>
From: "beikov (@beikov)" <noreply+beikov@github.com>
To: "pgjdbc/pgjdbc" <noreply+pgjdbc-pgjdbc@github.com>
Date: Fri, 27 Mar 2026 15:25:17 +0000
Subject: Re: [pgjdbc/pgjdbc] issue #2325: Support pipelining queries
In-Reply-To: <gh-pgjdbc-pgjdbc-2325@github.com>
References: <gh-pgjdbc-pgjdbc-2325@github.com>
List-Id: <gh-pgjdbc-pgjdbc.github.com>
X-GitHub-Author-Login: beikov
X-GitHub-Comment-Id: 4143405934
X-GitHub-Comment-Type: issue_comment
X-GitHub-Issue: 2325
X-GitHub-Repo: pgjdbc/pgjdbc
X-GitHub-Type: comment
X-GitHub-Url: https://github.com/pgjdbc/pgjdbc/issues/2325#issuecomment-4143405934
Content-Type: text/plain; charset=utf-8

> > connection between different non-virtual threads didn't seem like a good idea to me
> 
> > whereas with virtual threads it feels more natural
> 
> Why so?
> 
> I do not understand why sharing a connection between virtual threads should look any better than sharing connections between regular threads.
> 

In my mind, a connection is always used in a single threaded manner. Since virtual threads would usually (always?) run on the same carrier thread, the whole thing is more or less single-threaded, which is why it seems more natural to me. Anyway, if you think that people will spawn or share the connection with platform threads to achieve pipelining, then I'll test to see if that works as well.

> PS PostgreSQL backend semantics is "any failure kills the transaction". So, if a single SQL fails, all subsequent SQLs would fail as well until commit/rollback. That means, if virtual threads are unrelated, a single problematic would kill the results for all the others.

I don't understand why virtual threads would be the problem here. A connection is shared, so any thread that uses that connection has to understand the implications. Either way, a connection can fail due to communication errors any time, so not sure what you're trying to get at here.

> > JDBC batch API
> 
> It does not support select pipelining, it does not support pipelining queries of different shapes (e.g. insert / update pipelining).

I was thinking about `java.sql.Statement#addBatch(String)`, but that doesn't support parameters, which is unfortunate.

I heard that the Oracle JDBC driver folks toyed around with splitting the SQL string passed to `prepareStatement` on semi-colon and then pipeline these statements, which supports parameters, but requires numbering them for the whole string.

Anyway, my focus is on implementing support for pipelining such that it works with virtual threads, because that is the use case I want to work. I'll see if I can easily support platform threads and add that.