search

pgjdbc / pgadba

Implementation of Java 10 sql2 spec for PostgreSQL
BSD 2-Clause "Simplified" License
70 stars 10 forks source link

Discussion: PGOperationGroup.parallel #15

Closed sssinghsyr closed 6 years ago

sssinghsyr commented 6 years ago

PGOperationGroup.parallel states - "postgresql wire format doesn't allow parallel queries".

Using single connection, parallelism cannot be achieved. But can we assign multiple connections to a single OperationGroup and handle multiple Operations in parallel? I want to understand the USE_CASE of OperationGroup!

alexanderkjall commented 6 years ago

I think that letting one OperationGroup handle multiple connections would break the principle of least surprise, specially as starting a connection is a pretty expensive operation and every connection started results in a process fork on the database side.

Regarding OperationGroup: This is something I have struggled a lot with also, the OperationGroup class introduces a lot of complexity without having a super clear benefit for the user. With that said there is some use case for the 'held' functionality, it kind of works as a union query, but for more kinds of queries, read the class PGOperationGroupTest for examples.

I guess that there also is a flow control use case, with canceling of queries and catchOperation() but I haven't implemented that correctly yet, and to be honest I don't really see why it's needed.

It is also useful to be able to group a number of queries, and specify a timeout for all of them together, the timeout logic is still in need of implementation.

davecramer commented 6 years ago

Technically it is possible to issue multiple requests and get multiple answers back. That said it's difficult to decompose the multiple messages as there are no tags on the messages.

Dave Cramer

On 20 June 2018 at 14:16, Alexander Kjäll notifications@github.com wrote:

I think that letting one OperationGroup handle multiple connections would break the principle of least surprise, specially as starting a connection is a pretty expensive operation and every connection started results in a process fork on the database side.

Regarding OperationGroup: This is something I have struggled a lot with also, the OperationGroup class introduces a lot of complexity without having a super clear benefit for the user. With that said there is some use case for the 'held' functionality, it kind of works as a union query, but for more kinds of queries, read the class PGOperationGroupTest for examples.

I guess that there also is a flow control use case, with canceling of queries and catchOperation() but I haven't implemented that correctly yet, and to be honest I don't really see why it's needed.

It is also useful to be able to group a number of queries, and specify a timeout for all of them together, the timeout logic is still in need of implementation.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pgjdbc/pgsql2/issues/15#issuecomment-398846805, or mute the thread https://github.com/notifications/unsubscribe-auth/AAYz9rCZGK4iEuNrZ2CFvaLKRuW2Z0Qqks5t-pFngaJpZM4UvpnN .