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_abra...@bmc.com> 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.a...@cybertec.at>
> Sent: Saturday, November 4, 2023 11:07 PM
> To: Abraham, Danny <danny_abra...@bmc.com>; psql-performance 
> <pgsql-performa...@postgresql.org>
> 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


Reply via email to