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
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
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
Are you absolutely sure that the two databases you’re comparing the executing
with are identical, and that the objects involved in the query are physically
and logically identical?
The planning is done based on cost/statistics of the objects. If the statistics
are different, the planner may
Am 05.11.23 um 17:20 schrieb Abraham, Danny:
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?
*maybe* the driver changed some settings. You can check it with
select
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?
Thanks again
Danny
-Original Message-
From: Laurenz Albe
Sent: Saturday, November 4, 2023 11:07 PM
To: Abraham,
