| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Thomas Kellerer <spam_eater(at)gmx(dot)net> |
| Cc: | "pgsql-hackers(at)postgresql(dot)org" <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 18:01:47 |
| Message-ID: | CA+TgmoZZZ6p3-Ff3UMzqPOTqR6zxtE8L6roWVdUkXwGOW3eg3g@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-jdbc |
On Mon, Jan 18, 2016 at 5:50 PM, Thomas Kellerer <spam_eater(at)gmx(dot)net> wrote:
> 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.
The problem is that the floor is already littered with
potentially-very-beneficial query planning ideas that got discarded
because they would add too many cycles to planning time. Despite
that, planning time is a killer on some workloads. So right now we've
got workloads where we plan too much and workloads where we plan too
little. Argh.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Igal @ Lucee.org | 2016-01-19 18:08:13 | Re: make error - libpqdll.def No such file or directory |
| Previous Message | Robert Haas | 2016-01-19 17:58:38 | Re: checkpointer continuous flushing |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Kajaba | 2016-01-19 20:13:49 | Re: [pgjdbc] Implement JDBC specs via pre-processor step (#435) |
| Previous Message | Thom Brown | 2016-01-19 14:34:54 | Re: Patch: Implement failover on libpq connect level. |