Re: Re: [JDBC] 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Thomas Kellerer <spam_eater(at)gmx(dot)net>
Cc: PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Re: [JDBC] 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102
Date: 2016-01-19 04:49:30
Message-ID: CAFj8pRDbWU3XoFA2eY8tpuh-LJADv-e-J0UDAMQix-OqybSzkA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-jdbc

2016-01-18 23:50 GMT+01:00 Thomas Kellerer <spam_eater(at)gmx(dot)net>:

> Robert Haas wrote:
> > This isn't the first complaint about this mechanism that we've gotten,
> > and it won't be the last. Way too many of our users are way more
> > aware than they should be that the threshold here is five rather than
> > any other number, which to me is a clear-cut sign that this needs to
> > be improved. How to improve it is a harder question. We lack the
> > ability to do any kind of sensitivity analysis on a plan, so we can't
> > know whether there are other parameter values that would have resulted
> > in a different plan, nor can we test whether a particular set of
> > parameter values would have changed the outcome.
>
> (I initially posted that question on the JDBC mailing list)
>
> To be honest: looking at the efforts Oracle has done since 9 up until 12 I
> am not sure this is a problem that can be solved by caching plans.
>
> Even with the new "in-flight" re-planning in Oracle 12 ("cardinality
> feedback") and all the effort that goes into caching plans we are still
> seeing similar problems with (prepared) statements that are suddenly slow.
> And as far as I can tell, the infrastructure around plan caching,
> invalidation, bind variable peeking and all that seems to be a *lot* more
> complex ("sophisticated") in Oracle compared to Postgres. And the results
> don't seem to justify the effort (at least in my experience).
>
> With all the problems I have seen (in Oracle and Postgres) I think that
> maybe a better solution to this problem is to make the planner fast (and
> reliable) enough so that plan caching isn't necessary in the first place.
>
> However I have no idea how feasible that is.
>

for statements like INSERT INTO tab VALUES(..), UPDATE tab SET x = WHERE id
= .. will be planner significant overhead. But these statements are
relative simply and probably some solution is exists.

Regards

Pavel

>
>
>
>
>
> --
> View this message in context:
> http://postgresql.nabble.com/Fwd-JDBC-Re-9-4-1207-behaves-differently-with-server-side-prepared-statements-compared-to-9-2-1102-tp5881825p5882835.html
> Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2016-01-19 04:49:57 Re: exposing pg_controldata and pg_config as functions
Previous Message Amit Kapila 2016-01-19 04:28:33 Re: Re: BUG #13685: Archiving while idle every archive_timeout with wal_level hot_standby

Browse pgsql-jdbc by date

  From Date Subject
Next Message Pavel Kajaba 2016-01-19 11:53:24 Re: [pgjdbc] Implement JDBC specs via pre-processor step (#435)
Previous Message Thomas Kellerer 2016-01-18 22:50:08 Re: [JDBC] 9.4-1207 behaves differently with server side prepared statements compared to 9.2-1102