It would be nice to clarify is there any point in select queries pipelining

The following documentation comment has been logged on the website:

Page: https://www.postgresql.org/docs/16/protocol-flow.html
Description:

Greeting!
Please consider the following exchange with a PG database (Kotlin + Reactor+
r2dbc-postgresql):
```
295 1.063166 127.0.0.1 50591 127.0.0.1 32797 PGSQL 111

Q ---> BEGIN ISOLATION LEVEL REPEATABLE READ, READ WRITE

296 1.063219 127.0.0.1 32797 127.0.0.1 50591 TCP 56
32797 → 50591 [ACK] Seq=1 Ack=56 Win=6373 Len=0 TSval=3266177882
TSecr=3728690767
301 1.069912 127.0.0.1 32797 127.0.0.1 50591 PGSQL 73
<C/Z
302 1.069938 127.0.0.1 50591 127.0.0.1 32797 TCP 56
50591 → 32797 [ACK] Seq=56 Ack=18 Win=6370 Len=0 TSval=3728690774
TSecr=3266177889
712 1.099829 127.0.0.1 50591 127.0.0.1 32797 PGSQL 551

Q ------> select * from ... (#2)

713 1.099858 127.0.0.1 32797 127.0.0.1 50591 TCP 56
32797 → 50591 [ACK] Seq=18 Ack=551 Win=6365 Len=0 TSval=3266177919
TSecr=3728690804
715 1.099985 127.0.0.1 50591 127.0.0.1 32797 PGSQL 551

Q ------> select * from ... (#4)

717 1.100009 127.0.0.1 32797 127.0.0.1 50591 TCP 56
32797 → 50591 [ACK] Seq=18 Ack=1046 Win=6358 Len=0 TSval=3266177919
TSecr=3728690804
719 1.100082 127.0.0.1 50591 127.0.0.1 32797 PGSQL 551

Q ------> select * from ... (#1)

720 1.100106 127.0.0.1 32797 127.0.0.1 50591 TCP 56
32797 → 50591 [ACK] Seq=18 Ack=1541 Win=6350 Len=0 TSval=3266177919
TSecr=3728690804
722 1.100164 127.0.0.1 50591 127.0.0.1 32797 PGSQL 551

Q ------> select * from ... (#3)

723 1.100192 127.0.0.1 32797 127.0.0.1 50591 TCP 56
32797 → 50591 [ACK] Seq=18 Ack=2036 Win=6342 Len=0 TSval=3266177919
TSecr=3728690804
735 1.114695 127.0.0.1 32797 127.0.0.1 50591 PGSQL 424
<T/D/C/Z ------> Results for #2
737 1.114741 127.0.0.1 50591 127.0.0.1 32797 TCP 56
50591 → 32797 [ACK] Seq=2036 Ack=386 Win=6364 Len=0 TSval=3728690818
TSecr=3266177933
773 1.121732 127.0.0.1 32797 127.0.0.1 50591 PGSQL 1468
<T/D/D/D/D/D/D/D/D/D/D/D/D/C/Z ------> Results for #4
774 1.121757 127.0.0.1 50591 127.0.0.1 32797 TCP 56
50591 → 32797 [ACK] Seq=2036 Ack=1798 Win=6342 Len=0 TSval=3728690826
TSecr=3266177941
785 1.126793 127.0.0.1 32797 127.0.0.1 50591 PGSQL 594
<T/D/D/D/C/Z ------> Results for #1
786 1.126820 127.0.0.1 50591 127.0.0.1 32797 TCP 56
50591 → 32797 [ACK] Seq=2036 Ack=2336 Win=6334 Len=0 TSval=3728690831
TSecr=3266177946
805 1.135197 127.0.0.1 32797 127.0.0.1 50591 PGSQL 497
<T/D/D/C/Z ------> Results for #3
806 1.135222 127.0.0.1 50591 127.0.0.1 32797 TCP 56
50591 → 32797 [ACK] Seq=2036 Ack=2777 Win=6327 Len=0 TSval=3728690839
TSecr=3266177954
847 1.138848 127.0.0.1 50591 127.0.0.1 32797 PGSQL 68

Q ------> COMMIT

848 1.138876 127.0.0.1 32797 127.0.0.1 50591 TCP 56
32797 → 50591 [ACK] Seq=2777 Ack=2048 Win=6342 Len=0 TSval=3266177958
TSecr=3728690843
853 1.144624 127.0.0.1 32797 127.0.0.1 50591 PGSQL 74
<C/Z
```

The application code is the following (for the sake of clarity):
```
val transactionalOperator = TransactionalOperator.create(
transactionManager,
DefaultTransactionDefinition() .apply {
isolationLevel = TransactionDefinition.ISOLATION_REPEATABLE_READ
}
)

val users = Flux.defer {
Flux.create {
it.next(1)
it.next(2)
it.next(3)
it.next(4)
it.complete()
}
.parallel(4)
.runOn(Schedulers.parallel())
.flatMap {
databaseClient.sql(
"""
select * from …
""".trimIndent())
.map { row, _ -> EntityConverter().convert(row) }
.all()
.reduce(EntityReducer())
}
}.`as`(transactionalOperator::transactional)
```

I’m aware that Postgres doesn’t support cursor(portal) multiplexing so its
impossible to fetch data for two selects simultaneously but should I make
use of selects pipelining when I want to make the most of the DB? I mean to
say does a single Postgres backend employs concurrent processing and its
possible for a DB to transmit results for a query #2 (see the traffic) and
concurrently parse/rewrite/plan/optimize the subsequent (pipelined) queries
(issued from the same transaction). Neither chapter 55 nor 52 expand on it
(or it’s hard to spot at least).

Thanks!