Commit 7740991d authored by Bruce Momjian's avatar Bruce Momjian

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
>
parent 37cb2b77
PostgreSQL TODO List PostgreSQL TODO List
==================== ====================
Current maintainer: Bruce Momjian (bruce@momjian.us) 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 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.
...@@ -138,11 +138,13 @@ Administration ...@@ -138,11 +138,13 @@ Administration
o Allow a warm standby system to also allow read-only statements o Allow a warm standby system to also allow read-only statements
[pitr] [pitr]
This is useful for checking PITR recovery.
http://archives.postgresql.org/pgsql-hackers/2007-03/msg00050.php http://archives.postgresql.org/pgsql-hackers/2007-03/msg00050.php
o %Create dump tool for write-ahead logs for use in determining o %Create dump tool for write-ahead logs for use in determining
transaction id for point-in-time recovery transaction id for point-in-time recovery
This is useful for checking PITR recovery.
o Allow recovery.conf to support the same syntax as o Allow recovery.conf to support the same syntax as
postgresql.conf, including quoting postgresql.conf, including quoting
...@@ -979,7 +981,8 @@ Indexes ...@@ -979,7 +981,8 @@ Indexes
* Hash * 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 o Pack hash index buckets onto disk pages more efficiently
...@@ -1234,6 +1237,13 @@ Write-Ahead Log ...@@ -1234,6 +1237,13 @@ Write-Ahead Log
tables probably cannot have indexes. One complexity is the handling tables probably cannot have indexes. One complexity is the handling
of indexes on TOAST tables. 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 Optimizer / Executor
==================== ====================
......
...@@ -8,7 +8,7 @@ ...@@ -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:bruce@momjian.us">bruce@momjian.us</a>)<br/> <p>Current maintainer: Bruce Momjian (<a href="mailto:bruce@momjian.us">bruce@momjian.us</a>)<br/>
Last updated: Mon Mar 3 10:06:41 EST 2008 Last updated: Mon Mar 3 13:45:12 EST 2008
</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>.
...@@ -128,11 +128,12 @@ first. There is also a developer's wiki at<br/> ...@@ -128,11 +128,12 @@ first. There is also a developer's wiki at<br/>
<ul> <ul>
<li>Allow a warm standby system to also allow read-only statements <li>Allow a warm standby system to also allow read-only statements
[<a href="http://momjian.postgresql.org/cgi-bin/pgtodo?pitr">pitr</a>] [<a href="http://momjian.postgresql.org/cgi-bin/pgtodo?pitr">pitr</a>]
<p> This is useful for checking PITR recovery. <p> <a href="http://archives.postgresql.org/pgsql-hackers/2007-03/msg00050.php">http://archives.postgresql.org/pgsql-hackers/2007-03/msg00050.php</a>
<a href="http://archives.postgresql.org/pgsql-hackers/2007-03/msg00050.php">http://archives.postgresql.org/pgsql-hackers/2007-03/msg00050.php</a>
</p> </p>
</li><li>%Create dump tool for write-ahead logs for use in determining </li><li>%Create dump tool for write-ahead logs for use in determining
transaction id for point-in-time recovery transaction id for point-in-time recovery
<p> This is useful for checking PITR recovery.
</p>
</li><li>Allow recovery.conf to support the same syntax as </li><li>Allow recovery.conf to support the same syntax as
postgresql.conf, including quoting postgresql.conf, including quoting
<p> <a href="http://archives.postgresql.org/pgsql-hackers/2006-12/msg00497.php">http://archives.postgresql.org/pgsql-hackers/2006-12/msg00497.php</a> <p> <a href="http://archives.postgresql.org/pgsql-hackers/2006-12/msg00497.php">http://archives.postgresql.org/pgsql-hackers/2006-12/msg00497.php</a>
...@@ -871,25 +872,26 @@ first. There is also a developer's wiki at<br/> ...@@ -871,25 +872,26 @@ first. There is also a developer's wiki at<br/>
digital trees (see Aoki) digital trees (see Aoki)
</li></ul> </li></ul>
</li><li>Hash </li><li>Hash
<a href="http://archives.postgresql.org/pgsql-hackers/2007-09/msg00051.php">http://archives.postgresql.org/pgsql-hackers/2007-09/msg00051.php</a> </li></ul>
<ul> <p> <a href="http://archives.postgresql.org/pgsql-hackers/2007-09/msg00051.php">http://archives.postgresql.org/pgsql-hackers/2007-09/msg00051.php</a>
<li>Pack hash index buckets onto disk pages more efficiently </p>
<ul>
<li>Pack hash index buckets onto disk pages more efficiently
<p> Currently only one hash bucket can be stored on a page. Ideally <p> Currently only one hash bucket can be stored on a page. Ideally
several hash buckets could be stored on a single page and greater several hash buckets could be stored on a single page and greater
granularity used for the hash algorithm. granularity used for the hash algorithm.
</p> </p>
<p> <a href="http://archives.postgresql.org/pgsql-hackers/2004-06/msg00168.php">http://archives.postgresql.org/pgsql-hackers/2004-06/msg00168.php</a> <p> <a href="http://archives.postgresql.org/pgsql-hackers/2004-06/msg00168.php">http://archives.postgresql.org/pgsql-hackers/2004-06/msg00168.php</a>
</p> </p>
</li><li>Consider sorting hash buckets so entries can be found using a </li><li>Consider sorting hash buckets so entries can be found using a
binary search, rather than a linear scan binary search, rather than a linear scan
</li><li>In hash indexes, consider storing the hash value with or instead </li><li>In hash indexes, consider storing the hash value with or instead
of the key itself of the key itself
</li><li>Add WAL logging for crash recovery </li><li>Add WAL logging for crash recovery
</li><li>Allow multi-column hash indexes </li><li>Allow multi-column hash indexes
</li><li>During index creation, pre-sort the tuples to improve build speed </li><li>During index creation, pre-sort the tuples to improve build speed
<p> <a href="http://archives.postgresql.org/pgsql-hackers/2007-03/msg01199.php">http://archives.postgresql.org/pgsql-hackers/2007-03/msg01199.php</a> <p> <a href="http://archives.postgresql.org/pgsql-hackers/2007-03/msg01199.php">http://archives.postgresql.org/pgsql-hackers/2007-03/msg01199.php</a>
</p> </p>
</li></ul>
</li></ul> </li></ul>
<h1><a name="section_11">Fsync</a></h1> <h1><a name="section_11">Fsync</a></h1>
...@@ -1096,6 +1098,11 @@ first. There is also a developer's wiki at<br/> ...@@ -1096,6 +1098,11 @@ first. There is also a developer's wiki at<br/>
crash recovery. Readers can continue accessing the table. Such crash recovery. Readers can continue accessing the table. Such
tables probably cannot have indexes. One complexity is the handling tables probably cannot have indexes. One complexity is the handling
of indexes on TOAST tables. of indexes on TOAST tables.
</p>
</li><li>Speed WAL recovery by allowing more than one page to be prefetched
<p> This involves having a separate process that can be told which pages
the recovery process will need in the near future.
<a href="http://archives.postgresql.org/pgsql-hackers/2008-02/msg01279.php">http://archives.postgresql.org/pgsql-hackers/2008-02/msg01279.php</a>
</p> </p>
</li></ul> </li></ul>
<h1><a name="section_17">Optimizer / Executor</a></h1> <h1><a name="section_17">Optimizer / Executor</a></h1>
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment