database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-07-31 22:04:40 +03:00
Code Activity

Done:

Browse Source 
< Last updated:		Sat May  5 10:47:39 EDT 2007
> Last updated:		Sat May  5 11:39:57 EDT 2007
< * Flush cached query plans when the dependent objects change,
<   when the cardinality of parameters changes dramatically, or
> * -Flush cached query plans when the dependent objects change or
<
<   A more complex solution would be to save multiple plans for different
<   cardinality and use the appropriate plan based on the EXECUTE values.
<
< * Track dependencies in function bodies and recompile/invalidate
<
<   This is particularly important for references to temporary tables
<   in PL/PgSQL because PL/PgSQL caches query plans.  The only workaround
<   in PL/PgSQL is to use EXECUTE.  One complexity is that a function
<   might itself drop and recreate dependent tables, causing it to
<   invalidate its own query plan.
<
< * Invalidate prepared queries, like INSERT, when the table definition
> * -Track dependencies in function bodies and recompile/invalidate
> * -Invalidate prepared queries, like INSERT, when the table definition
This commit is contained in:
Bruce Momjian
2007-05-05 15:40:01 +00:00
parent dc9d3947e6
commit 4835df303d
2 changed files with 37 additions and 57 deletions
Download Patch File Download Diff File Expand all files Collapse all files

22
doc/TODO
View File

@ -1,8 +1,8 @@
z
PostgreSQL TODO List
====================
Current maintainer: Bruce Momjian (bruce@momjian.us)
Last updated: Sat May 5 10:47:39 EDT 2007
Last updated: Sat May 5 11:39:57 EDT 2007
The most recent version of this document can be viewed at
http://www.postgresql.org/docs/faqs.TODO.html.
@ -958,22 +958,10 @@ Triggers
Dependency Checking
===================
* Flush cached query plans when the dependent objects change,
when the cardinality of parameters changes dramatically, or
* -Flush cached query plans when the dependent objects change or
when new ANALYZE statistics are available
A more complex solution would be to save multiple plans for different
cardinality and use the appropriate plan based on the EXECUTE values.
* Track dependencies in function bodies and recompile/invalidate
This is particularly important for references to temporary tables
in PL/PgSQL because PL/PgSQL caches query plans. The only workaround
in PL/PgSQL is to use EXECUTE. One complexity is that a function
might itself drop and recreate dependent tables, causing it to
invalidate its own query plan.
* Invalidate prepared queries, like INSERT, when the table definition
* -Track dependencies in function bodies and recompile/invalidate
* -Invalidate prepared queries, like INSERT, when the table definition
is altered