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.
>
This commit is contained in:
Bruce Momjian 2005-12-22 23:05:32 +00:00
parent 656beff590
commit 2f1a78e200
2 changed files with 9 additions and 2 deletions

View File

@ -2,7 +2,7 @@
PostgreSQL TODO List PostgreSQL TODO List
==================== ====================
Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us) 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 The most recent version of this document can be viewed at
http://www.postgresql.org/docs/faqs.TODO.html. http://www.postgresql.org/docs/faqs.TODO.html.
@ -718,6 +718,10 @@ Dependency Checking
* Flush cached query plans when the dependent objects change, * Flush cached query plans when the dependent objects change,
when the cardinality of parameters changes dramatically, or when the cardinality of parameters changes dramatically, or
when new ANALYZE statistics are available 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 * Track dependencies in function bodies and recompile/invalidate
This is particularly important for references to temporary tables This is particularly important for references to temporary tables

View File

@ -8,7 +8,7 @@
<body bgcolor="#FFFFFF" text="#000000" link="#FF0000" vlink="#A00000" alink="#0000FF"> <body bgcolor="#FFFFFF" text="#000000" link="#FF0000" vlink="#A00000" alink="#0000FF">
<h1><a name="section_1">PostgreSQL TODO List</a></h1> <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/> <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>
<p>The most recent version of this document can be viewed at<br/> <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>. <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, <li>Flush cached query plans when the dependent objects change,
when the cardinality of parameters changes dramatically, or when the cardinality of parameters changes dramatically, or
when new ANALYZE statistics are available 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 </li><li>Track dependencies in function bodies and recompile/invalidate
<p> This is particularly important for references to temporary tables <p> This is particularly important for references to temporary tables
in PL/PgSQL because PL/PgSQL caches query plans. The only workaround in PL/PgSQL because PL/PgSQL caches query plans. The only workaround