From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
---|---|
To: | laurent(dot)dechambe(at)orange(dot)com, Andreas Kretschmer <andreas(at)a-kretschmer(dot)de>, "pgsql-performance(at)lists(dot)postgresql(dot)org" <pgsql-performance(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Pg10 : Client Configuration for Parallelism ? |
Date: | 2019-04-17 17:11:42 |
Message-ID: | 86bd000a7270215b5322d73fdac4ab2c8aa4f520.camel@cybertec.at |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
laurent(dot)dechambe(at)orange(dot)com wrote:
> There is something in documentation that says that there won't be parallelism
> if " The client sends an Execute message with a non-zero fetch count."
> I am not sure what this sentence means.
The JDBC driver sends an "Execute" message to the server.
https://www.postgresql.org/docs/current/protocol-message-formats.html says:
Execute (F)
Byte1('E')
Identifies the message as an Execute command.
Int32
Length of message contents in bytes, including self.
String
The name of the portal to execute (an empty string selects the unnamed portal).
Int32
Maximum number of rows to return, if portal contains a query that returns rows
(ignored otherwise). Zero denotes “no limit”.
If you use setMaxRows non-zero, that number is sent as the "maximum number of rows".
Parallelism currently cannot be used if there is a limit on the row count.
Imagine you want ten rows and already have nine, now if two workers are busy
calculating the next row, there is no good way to stop one of them when the other
returns a row.
Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2019-04-17 20:14:59 | Re: Block / Page Size Optimization |
Previous Message | laurent.dechambe | 2019-04-17 14:33:28 | RE: Pg10 : Client Configuration for Parallelism ? |