From 62c06186f55f7968f432bfc16ea2b6a7150698a6 Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Sat, 13 Jan 2007 15:13:44 +0000 Subject: [PATCH] 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 --- doc/TODO | 15 +-------------- doc/src/FAQ/TODO.html | 13 +------------ 2 files changed, 2 insertions(+), 26 deletions(-) diff --git a/doc/TODO b/doc/TODO index 6b9fd4bbcd..1b68a55501 100644 --- a/doc/TODO +++ b/doc/TODO @@ -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 diff --git a/doc/src/FAQ/TODO.html b/doc/src/FAQ/TODO.html index 42b23e2267..45e1b26546 100644 --- a/doc/src/FAQ/TODO.html +++ b/doc/src/FAQ/TODO.html @@ -8,7 +8,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. @@ -614,9 +614,6 @@ first.

  • Allow PL/RETURN to return row or record functions

    http://archives.postgresql.org/pgsql-patches/2005-11/msg00045.php -

    -
  • Fix memory leak from exceptions -

    http://archives.postgresql.org/pgsql-performance/2006-06/msg00305.php

  • 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
  • -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

    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. -

    -
  • 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