| From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
|---|---|
| To: | "Abraham, Danny" <danny_abraham(at)bmc(dot)com> |
| Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, psql-performance <pgsql-performance(at)postgresql(dot)org>, "Shivatski, Sagi" <sagi_shivatski(at)bmc(dot)com> |
| Subject: | Re: [EXTERNAL] Re: Performance down with JDBC 42 |
| Date: | 2023-11-05 19:11:46 |
| Message-ID: | CAMkU=1xSq_v1SvUGKpLzHCpvJ6PF3QnmFOx53+2h4zSvj_AFfQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Sun, Nov 5, 2023 at 11:20 AM Abraham, Danny <danny_abraham(at)bmc(dot)com>
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 drivers fetch
partial results is different, such that with one the planner knows to
expect only partial results to be fetched and with the other it does not.
So in one case it chooses the fast-start plan, and in the other it
doesn't. But it will be hard to get anywhere if you just dribble
information at us a bit at a time. Can you come up with a self-contained
test case? Or at least show the entirety of both plans?
Cheers,
Jeff
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Abraham, Danny | 2023-11-05 19:37:12 | RE: [EXTERNAL] Re: Performance down with JDBC 42 |
| Previous Message | Frits Hoogland | 2023-11-05 17:34:57 | Re: [EXTERNAL] Re: Performance down with JDBC 42 |