Update item:

> > A more complex solution would be to save multiple plans for different > cardinality and use the appropriate plan based on the EXECUTE values. >

Update item:
> > A more complex solution would be to save multiple plans for different > cardinality and use the appropriate plan based on the EXECUTE values. >
2f1a78e2 · Bruce Momjian · 656beff5 · 2f1a78e2 · 2f1a78e2
隐藏空白更改
内联并排

Showing with 9 addition and 2 deletion

doc/TODO doc/TODO +5 -1

doc/src/FAQ/TODO.html doc/src/FAQ/TODO.html +4 -1

未找到文件。
--- a/doc/TODO
+++ b/doc/TODO
@@ -2,7 +2,7 @@
 PostgreSQL TODO List
 ====================
 Current maintainer:	Bruce Momjian (pgman@candle.pha.pa.us)
-Last updated:		Sat Dec 17 14:03:20 EST 2005
+Last updated:		Thu Dec 22 18:05:31 EST 2005
 The most recent version of this document can be viewed at
 http://www.postgresql.org/docs/faqs.TODO.html.
@@ -718,6 +718,10 @@ Dependency Checking
 * Flush cached query plans when the dependent objects change,
  when the cardinality of parameters changes dramatically, 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

--- a/doc/src/FAQ/TODO.html
+++ b/doc/src/FAQ/TODO.html
@@ -8,7 +8,7 @@
 <body bgcolor="#FFFFFF" text="#000000" link="#FF0000" vlink="#A00000" alink="#0000FF">
 <h1><a name="section_1">PostgreSQL TODO List</a></h1>
 <p>Current maintainer:     Bruce Momjian (<a href="mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</a>)<br/>
-Last updated:           Sat Dec 17 14:03:20 EST 2005
+Last updated:           Thu Dec 22 18:05:31 EST 2005
 </p>
 <p>The most recent version of this document can be viewed at<br/>
 <a href="http://www.postgresql.org/docs/faqs.TODO.html">http://www.postgresql.org/docs/faqs.TODO.html</a>.
@@ -655,6 +655,9 @@ first.
  <li>Flush cached query plans when the dependent objects change,
  when the cardinality of parameters changes dramatically, or
  when new ANALYZE statistics are available
+<p>  A more complex solution would be to save multiple plans for different
+  cardinality and use the appropriate plan based on the EXECUTE values.
+</p>
  </li><li>Track dependencies in function bodies and recompile/invalidate
 <p>  This is particularly important for references to temporary tables
  in PL/PgSQL because PL/PgSQL caches query plans.  The only workaround