| From: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Peter van Hardenberg <pvh(at)pvh(dot)ca>, Peter Geoghegan <peter(dot)geoghegan86(at)gmail(dot)com>, "pgsql-hackers\(at)postgresql(dot)org Hackers" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Prepared statements fail after schema changes with surprising error |
| Date: | 2013-01-23 13:10:54 |
| Message-ID: | m2ehhccae9.fsf@2ndQuadrant.fr |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> I'm thinking that the main argument for trying to do this is so that we
> could say "plan caching is transparent", full stop, with no caveats or
> corner cases. But removing those caveats is going to cost a fair
> amount, and it looks like that cost will be wasted for most usage
> patterns.
I think the right thing to do here is aim for transparent plan caching.
Now, will the caveats only apply when there has been some live DDL
running, or even only DDL that changes schemas (not objects therein)?
Really, live DDL is not that frequent, and when you do that, you want
transparent replanning. I can't see any use case where it's important to
be able to run DDL in a live application yet continue to operate with
the old (and in cases wrong) plans.
Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Zoltán Böszörményi | 2013-01-23 13:28:25 | Re: Strange Windows problem, lock_timeout test request |
| Previous Message | Andres Freund | 2013-01-23 12:14:13 | Re: logical changeset generation v4 |