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