Alvaro Herrera <[EMAIL PROTECTED]> writes:
> This is where the interesting questions are:
> http://archives.postgresql.org/message-id/10333.1219179364%40sss.pgh.pa.us
Upthread, someone speculated about solving the problem by forcing plan
cache flush on *any* catalog change. I think that's probably not
acceptable from an efficiency standpoint. But maybe it'd be a good idea
to special-case common cases and fall back to a stupid flush for less
common cases, rather than invest all the work that'd be needed to track
every direct and indirect dependency of every plan. My first thought
along these lines is:
* track table dependencies exactly (important for efficiency, plus we've
got the code already)
* track function dependencies exactly (seems function definitions might
change often enough to make it important for efficiency; maybe only
track PL function dependencies??)
* brute-force flush for any other catalog change that could affect plans
However I have no hard evidence to back up drawing the line there rather
than somewhere else. Anyone have data on what sort of DDL changes are
common in their applications?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
