On Wed, Apr 17, 2019 at 09:51:02AM +0000, laurent.dechambe@orange.com wrote:
> <DBEAVER>
> 2019-04-17 11:30:42 CEST;35895;thedbuser;thedb;00000;LOG: 00000: execute <unnamed>: SELECT COUNT(1) FROM big_table
> 2019-04-17 11:30:42 CEST;35895;thedbuser;thedb;00000;LOCATION: exec_execute_message, postgres.c:1959
"execute" means it's using the extended protocol.
https://www.postgresql.org/docs/11/protocol-flow.html#PROTOCOL-FLOW-EXT-QUERY
> <BASIC JDBC>
> 2019-04-17 11:31:20 CEST;37257;thedbuser;thedb;00000;LOG: 00000: execute <unnamed>: SELECT COUNT(1) FROM big_table
> 2019-04-17 11:31:20 CEST;37257;thedbuser;thedb;00000;LOCATION: exec_execute_message, postgres.c:1959
Same.
> <PGADMIN4>
> 2019-04-17 11:32:56 CEST;37324;thedbuser;thedb;00000;LOG: 00000: statement: SELECT COUNT(1) FROM big_table;
> 2019-04-17 11:32:56 CEST;37324;thedbuser;thedb;00000;LOCATION: exec_simple_query, postgres.c:940
This is a "simple query", not using the "extended protocol".
On Wed, Apr 17, 2019 at 11:26:07AM +0000, laurent.dechambe@orange.com wrote:
> There is something in documentation that says that there won't be parallelism if " The client sends an Execute
messagewith a non-zero fetch count."
> I am not sure what this sentence means.
This is likely the cause of the difference.
Could you run wireshark to watch the protocol traffic ?
I think it'll show that dbeaver is retrieving a portion of the result set.
Justin