From: | David Fetter <david(at)fetter(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Hannu Krosing <hannu(at)2ndQuadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, pgsql-hackers(at)postgresql(dot)org, Zdenek Kotala <Zdenek(dot)Kotala(at)Sun(dot)COM> |
Subject: | Re: Patch: plan invalidation vs stored procedures |
Date: | 2008-08-20 02:28:54 |
Message-ID: | 20080820022854.GA7447@fetter.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 19, 2008 at 09:50:53PM -0400, Tom Lane wrote:
> David Fetter <david(at)fetter(dot)org> writes:
> > On Tue, Aug 19, 2008 at 07:45:16PM -0400, Tom Lane wrote:
> >> FWIW, given that there will probably always be corner cases. I can
> >> see the attraction in Simon's suggestion of providing a way to
> >> manually issue a system-wide forced plan flush.
>
> > Would that require a system-wide plan cache to implement?
>
> No, just a function that can issue a suitable sinval message.
>
> plancache.c would already respond in the desired way to a relcache inval
> message with OID = 0, though likely it'll be cleaner to invent an sinval
> message type specifically for the purpose.
>
> One thing to think about is whether the flush should be truly
> system-wide or just database-wide. I can see a lot more uses for the
> latter than the former --- I don't think there's a reason for cached
> plans to depend on any contents of the shared catalogs.
They might during an on-line upgrade.
Zdenek?
Cheers,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)com
Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Treat | 2008-08-20 02:33:42 | Re: A smaller default postgresql.conf |
Previous Message | Tom Lane | 2008-08-20 02:28:32 | Re: Adjusting debug_print_plan to be more useful by default |