On Wed, Apr 17, 2019 at 09:51:02AM +0000, laurent.decha...@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.decha...@orange.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. 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
