On Mon, 6 Nov 2023 at 08:37, Abraham, Danny wrote:
>
> Both plans refer to the same DB.
JDBC is making use of PREPARE statements, whereas psql, unless you're
using PREPARE is not.
> #1 – Fast – using psql or old JDBC driver
The absence of any $1 type parameters here shows that's a custom plan
t
Thanks for the help.
Both plans refer to the same DB.
#1 – Fast – using psql or old JDBC driver
==>
Sort (cost=13113.27..13113.33 rows=24 width=622)
Output: dm.calname, dm.jobyear, dm.caltype, ((dm.daymask)::character
varying(400))
Sort Key: dm.calname, dm.jobyear
-> HashAggregate (co
On Sun, Nov 5, 2023 at 11:20 AM Abraham, Danny
wrote:
> Thanks Laurenz,
>
> Traced two huge plans. They differ.
> The fast one does use Materialize and Memoize (the psql).
> Is there something in JDBC 42 that blocks these algoruthms?
Directly blocking those is not likely. Maybe the way the dri
blocks these algoruthms?
>
> Thanks again
>
> Danny
>
> -Original Message-
> From: Laurenz Albe
> Sent: Saturday, November 4, 2023 11:07 PM
> To: Abraham, Danny ; psql-performance
>
> Subject: [EXTERNAL] Re: Performance down with JDBC 42
>
>> On S
name, setting from pg_settings where name ~ 'enable';
using the JDBC-connection.
Regards, Andreas
Thanks again
Danny
-Original Message-
From: Laurenz Albe
Sent: Saturday, November 4, 2023 11:07 PM
To: Abraham, Danny ; psql-performance
Subject: [EXTERNAL] Re: Performance
, Danny ; psql-performance
Subject: [EXTERNAL] Re: Performance down with JDBC 42
On Sat, 2023-11-04 at 19:08 +, Abraham, Danny wrote:
> Asking for help with a JDBC related issue.
> Environment: Linux 7.9 PG 14.9 , very busy PG Server.
>
> A big query - 3 unions and about 1
