From 7740991d52e8e198a3ca62b606fcdb26c98b11ae Mon Sep 17 00:00:00 2001
From: Bruce Momjian
Date: Mon, 3 Mar 2008 18:45:24 +0000
Subject: [PATCH] Add:
> * Speed WAL recovery by allowing more than one page to be prefetched
>
> This involves having a separate process that can be told which pages
> the recovery process will need in the near future.
> http://archives.postgresql.org/pgsql-hackers/2008-02/msg01279.php
>
---
doc/TODO | 16 +++++++++++++---
doc/src/FAQ/TODO.html | 31 +++++++++++++++++++------------
2 files changed, 32 insertions(+), 15 deletions(-)
diff --git a/doc/TODO b/doc/TODO
index cb0389adb6..49beae2077 100644
--- a/doc/TODO
+++ b/doc/TODO
@@ -1,7 +1,7 @@
PostgreSQL TODO List
====================
Current maintainer: Bruce Momjian (bruce@momjian.us)
-Last updated: Mon Mar 3 10:06:41 EST 2008
+Last updated: Mon Mar 3 13:45:12 EST 2008
The most recent version of this document can be viewed at
http://www.postgresql.org/docs/faqs.TODO.html.
@@ -138,11 +138,13 @@ Administration
o Allow a warm standby system to also allow read-only statements
[pitr]
- This is useful for checking PITR recovery.
http://archives.postgresql.org/pgsql-hackers/2007-03/msg00050.php
o %Create dump tool for write-ahead logs for use in determining
transaction id for point-in-time recovery
+
+ This is useful for checking PITR recovery.
+
o Allow recovery.conf to support the same syntax as
postgresql.conf, including quoting
@@ -979,7 +981,8 @@ Indexes
* Hash
- http://archives.postgresql.org/pgsql-hackers/2007-09/msg00051.php
+
+ http://archives.postgresql.org/pgsql-hackers/2007-09/msg00051.php
o Pack hash index buckets onto disk pages more efficiently
@@ -1234,6 +1237,13 @@ Write-Ahead Log
tables probably cannot have indexes. One complexity is the handling
of indexes on TOAST tables.
+* Speed WAL recovery by allowing more than one page to be prefetched
+
+ This involves having a separate process that can be told which pages
+ the recovery process will need in the near future.
+ http://archives.postgresql.org/pgsql-hackers/2008-02/msg01279.php
+
+
Optimizer / Executor
====================
diff --git a/doc/src/FAQ/TODO.html b/doc/src/FAQ/TODO.html
index b47d2564d8..750e64cb78 100644
--- a/doc/src/FAQ/TODO.html
+++ b/doc/src/FAQ/TODO.html
@@ -8,7 +8,7 @@
Current maintainer: Bruce Momjian (bruce@momjian.us)
-Last updated: Mon Mar 3 10:06:41 EST 2008
+Last updated: Mon Mar 3 13:45:12 EST 2008
The most recent version of this document can be viewed at
http://www.postgresql.org/docs/faqs.TODO.html.
@@ -128,11 +128,12 @@ first. There is also a developer's wiki at
Hash
- http://archives.postgresql.org/pgsql-hackers/2007-09/msg00051.php
-
- - Pack hash index buckets onto disk pages more efficiently
+
+ http://archives.postgresql.org/pgsql-hackers/2007-09/msg00051.php
+
+
+ - Pack hash index buckets onto disk pages more efficiently
Currently only one hash bucket can be stored on a page. Ideally
several hash buckets could be stored on a single page and greater
granularity used for the hash algorithm.
http://archives.postgresql.org/pgsql-hackers/2004-06/msg00168.php
- - Consider sorting hash buckets so entries can be found using a
+
- Consider sorting hash buckets so entries can be found using a
binary search, rather than a linear scan
-
- In hash indexes, consider storing the hash value with or instead
+
- In hash indexes, consider storing the hash value with or instead
of the key itself
-
- Add WAL logging for crash recovery
-
- Allow multi-column hash indexes
-
- During index creation, pre-sort the tuples to improve build speed
+
- Add WAL logging for crash recovery
+
- Allow multi-column hash indexes
+
- During index creation, pre-sort the tuples to improve build speed
http://archives.postgresql.org/pgsql-hackers/2007-03/msg01199.php
-
@@ -1096,6 +1098,11 @@ first. There is also a developer's wiki at
crash recovery. Readers can continue accessing the table. Such
tables probably cannot have indexes. One complexity is the handling
of indexes on TOAST tables.
+
+ Speed WAL recovery by allowing more than one page to be prefetched
+ This involves having a separate process that can be told which pages
+ the recovery process will need in the near future.
+ http://archives.postgresql.org/pgsql-hackers/2008-02/msg01279.php