From 754838caa3524121bc12f86fd16b53a3a0e8d472 Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Thu, 20 Sep 2007 18:54:19 +0000 Subject: [PATCH] Done: > * -Consider shrinking expired tuples to just their headers > * -Allow heap reuse of UPDATEd rows if no indexed columns are changed, > and old and new versions are on the same heap page Not needed anymore: < * Reuse index tuples that point to heap tuples that are not visible to < anyone? --- doc/TODO | 23 ++++------------------- doc/src/FAQ/TODO.html | 21 ++++----------------- 2 files changed, 8 insertions(+), 36 deletions(-) diff --git a/doc/TODO b/doc/TODO index 862059834e..8be1609e27 100644 --- a/doc/TODO +++ b/doc/TODO @@ -1,7 +1,7 @@ PostgreSQL TODO List ==================== Current maintainer: Bruce Momjian (bruce@momjian.us) -Last updated: Fri Sep 14 15:02:41 EDT 2007 +Last updated: Thu Sep 20 14:53:32 EDT 2007 The most recent version of this document can be viewed at http://www.postgresql.org/docs/faqs.TODO.html. @@ -1208,24 +1208,9 @@ Vacuum in hopes that empty pages at the end can be truncated by VACUUM * Allow FSM page return free space based on table clustering, to assist in maintaining clustering? -* Consider shrinking expired tuples to just their headers - - http://archives.postgresql.org/pgsql-patches/2006-03/msg00142.php - http://archives.postgresql.org/pgsql-hackers/2007-01/msg01025.php - -* Allow heap reuse of UPDATEd rows if no indexed columns are changed, - and old and new versions are on the same heap page? - - While vacuum handles DELETEs fine, updating of non-indexed columns, like - counters, are difficult for VACUUM to handle efficiently. This method - is possible for same-page updates because a single index row can be - used to point to both old and new values. - - http://archives.postgresql.org/pgsql-hackers/2006-06/msg01305.php - http://archives.postgresql.org/pgsql-hackers/2006-06/msg01534.php - -* Reuse index tuples that point to heap tuples that are not visible to - anyone? +* -Consider shrinking expired tuples to just their headers +* -Allow heap reuse of UPDATEd rows if no indexed columns are changed, + and old and new versions are on the same heap page * Improve dead row detection during multi-statement transactions usage http://archives.postgresql.org/pgsql-patches/2007-03/msg00358.php diff --git a/doc/src/FAQ/TODO.html b/doc/src/FAQ/TODO.html index 932bc9f536..2aec563e4c 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: Fri Sep 14 15:02:41 EDT 2007 +Last updated: Thu Sep 20 14:53:32 EDT 2007

The most recent version of this document can be viewed at
http://www.postgresql.org/docs/faqs.TODO.html. @@ -1075,22 +1075,9 @@ first. There is also a developer's wiki at
in hopes that empty pages at the end can be truncated by VACUUM

  • Allow FSM page return free space based on table clustering, to assist in maintaining clustering? -
  • Consider shrinking expired tuples to just their headers -

    http://archives.postgresql.org/pgsql-patches/2006-03/msg00142.php - http://archives.postgresql.org/pgsql-hackers/2007-01/msg01025.php -

    -
  • Allow heap reuse of UPDATEd rows if no indexed columns are changed, - and old and new versions are on the same heap page? -

    While vacuum handles DELETEs fine, updating of non-indexed columns, like - counters, are difficult for VACUUM to handle efficiently. This method - is possible for same-page updates because a single index row can be - used to point to both old and new values. -

    -

    http://archives.postgresql.org/pgsql-hackers/2006-06/msg01305.php - http://archives.postgresql.org/pgsql-hackers/2006-06/msg01534.php -

    -
  • Reuse index tuples that point to heap tuples that are not visible to - anyone? +
  • -Consider shrinking expired tuples to just their headers +
  • -Allow heap reuse of UPDATEd rows if no indexed columns are changed, + and old and new versions are on the same heap page
  • Improve dead row detection during multi-statement transactions usage

    http://archives.postgresql.org/pgsql-patches/2007-03/msg00358.php

    -- 2.40.0