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 come up with another plan. Frits > Op 5 nov 2023 om 17:20 heeft Abraham, Danny <danny_abraham@xxxxxxx> het volgende geschreven: > > 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 <laurenz.albe@xxxxxxxxxxx> > Sent: Saturday, November 4, 2023 11:07 PM > To: Abraham, Danny <danny_abraham@xxxxxxx>; psql-performance <pgsql-performance@xxxxxxxxxxxxxx> > Subject: [EXTERNAL] Re: Performance down with JDBC 42 > >> On Sat, 2023-11-04 at 19:08 +0000, 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 10 joins runs : >> - 70ms on psql , DBeaver with JDBC 42 and in our Server using old >> JDBC 9.2 >> - 2500 ms in our Server using new JDBC 42 driver. ( and this is >> running many times) >> >> Question: Is there a structured way to identify optimization setup ( Planner Method s ) changes? >> Are there any known changes specific to JDBC 42. > > What I would do is enable auto_explain and look at the execution plan when the statement is run by the JDBC driver. Then you can compare the execution plans and spot the difference. > > Yours, > Laurenz Albe
