rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Remove completed items, and the last is unwanted: 

< 		o Fix memory leak from exceptions
<
< 		  http://archives.postgresql.org/pgsql-performance/2006-06/msg00305.php
<
< * Allow constraint_exclusion to work for UNIONs like it does for
<   inheritance, allow it to work for UPDATE and DELETE statements, and allow
<   it to be used for all statements with little performance impact
<
< * Add estimated_count(*) to return an estimate of COUNT(*)
<
<   This would use the planner ANALYZE statistics to return an estimated
<   count.
<   http://archives.postgresql.org/pgsql-hackers/2005-11/msg00943.php
This commit is contained in:
Bruce Momjian 2007-01-13 15:13:44 +00:00
parent 9a54b76b39
commit 62c06186f5
2 changed files with 2 additions and 26 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
doc/TODO
View File

@ -2,7 +2,7 @@
PostgreSQL TODO List
====================
Current maintainer: Bruce Momjian (bruce@momjian.us)
Last updated: Wed Jan 10 23:48:50 EST 2007
Last updated: Sat Jan 13 10:13:24 EST 2007
The most recent version of this document can be viewed at
http://www.postgresql.org/docs/faqs.TODO.html.
@ -680,10 +680,6 @@ SQL Commands
http://archives.postgresql.org/pgsql-patches/2005-11/msg00045.php
o Fix memory leak from exceptions
http://archives.postgresql.org/pgsql-performance/2006-06/msg00305.php
o Fix problems with RETURN NEXT on tables with
dropped/added columns after function creation
@ -897,9 +893,6 @@ Indexes
one column or expression indexes, perhaps using per-index statistics
* -Allow the creation of indexes with mixed ascending/descending
specifiers
* Allow constraint_exclusion to work for UNIONs like it does for
inheritance, allow it to work for UPDATE and DELETE statements, and allow
it to be used for all statements with little performance impact
* Consider compressing indexes by storing key values duplicated in
several rows as a single index entry
@ -979,12 +972,6 @@ Cache Usage
faster than a sequential scan it must avoid access to the heap
to obtain tuple visibility information.
* Add estimated_count(*) to return an estimate of COUNT(*)
This would use the planner ANALYZE statistics to return an estimated
count.
http://archives.postgresql.org/pgsql-hackers/2005-11/msg00943.php
* Allow data to be pulled directly from indexes
Currently indexes do not have enough tuple visibility information

13
doc/src/FAQ/TODO.html
View File

@ -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:bruce@momjian.us">bruce@momjian.us</a>)<br/>
Last updated: Wed Jan 10 23:48:50 EST 2007
Last updated: Sat Jan 13 10:13:24 EST 2007
</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>.
@ -614,9 +614,6 @@ first.
</p>
</li><li>Allow PL/RETURN to return row or record functions
<p> <a href="http://archives.postgresql.org/pgsql-patches/2005-11/msg00045.php">http://archives.postgresql.org/pgsql-patches/2005-11/msg00045.php</a>
</p>
</li><li>Fix memory leak from exceptions
<p> <a href="http://archives.postgresql.org/pgsql-performance/2006-06/msg00305.php">http://archives.postgresql.org/pgsql-performance/2006-06/msg00305.php</a>
</p>
</li><li>Fix problems with RETURN NEXT on tables with
dropped/added columns after function creation
@ -810,9 +807,6 @@ first.
one column or expression indexes, perhaps using per-index statistics
</li><li>-<em>Allow the creation of indexes with mixed ascending/descending</em>
specifiers
</li><li>Allow constraint_exclusion to work for UNIONs like it does for
inheritance, allow it to work for UPDATE and DELETE statements, and allow
it to be used for all statements with little performance impact
</li><li>Consider compressing indexes by storing key values duplicated in
several rows as a single index entry
<p> This is difficult because it requires datatype-specific knowledge.
@ -879,11 +873,6 @@ first.
get a count directly from a unique index, but for this to be
faster than a sequential scan it must avoid access to the heap
to obtain tuple visibility information.
</p>
</li><li>Add estimated_count(*) to return an estimate of COUNT(*)
<p> This would use the planner ANALYZE statistics to return an estimated
count.
<a href="http://archives.postgresql.org/pgsql-hackers/2005-11/msg00943.php">http://archives.postgresql.org/pgsql-hackers/2005-11/msg00943.php</a>
</p>
</li><li>Allow data to be pulled directly from indexes
<p> Currently indexes do not have enough tuple visibility information