Skip to content

P
Postgres FD Implementation
Commit 7740991d authored by Bruce Momjian's avatar Bruce Momjian
Browse files
Options

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
Hide whitespace changes
Inline Side-by-side
Showing with 32 additions and 15 deletions
doc/TODO
View file @ 7740991d
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
====================
......
doc/src/FAQ/TODO.html
View file @ 7740991d
......@@ -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: Mon Mar 3 10:06:41 EST 2008
Last updated: Mon Mar 3 13:45:12 EST 2008
</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>.
......@@ -128,11 +128,12 @@ first. There is also a developer's wiki at<br/>
<ul>
<li>Allow a warm standby system to also allow read-only statements
[<a href="http://momjian.postgresql.org/cgi-bin/pgtodo?pitr">pitr</a>]
<p> This is useful for checking PITR recovery.
<a href="http://archives.postgresql.org/pgsql-hackers/2007-03/msg00050.php">http://archives.postgresql.org/pgsql-hackers/2007-03/msg00050.php</a>
<p> <a href="http://archives.postgresql.org/pgsql-hackers/2007-03/msg00050.php">http://archives.postgresql.org/pgsql-hackers/2007-03/msg00050.php</a>
</p>
</li><li>%Create dump tool for write-ahead logs for use in determining
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
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>
......@@ -871,25 +872,26 @@ first. There is also a developer's wiki at<br/>
digital trees (see Aoki)
</li></ul>
</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>
<ul>
<li>Pack hash index buckets onto disk pages more efficiently
</li></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>
</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
several hash buckets could be stored on a single page and greater
granularity used for the hash algorithm.
</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>
</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
</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
</li><li>Add WAL logging for crash recovery
</li><li>Allow multi-column hash indexes
</li><li>During index creation, pre-sort the tuples to improve build speed
</li><li>Add WAL logging for crash recovery
</li><li>Allow multi-column hash indexes
</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>
</li></ul>
</li></ul>
<h1><a name="section_11">Fsync</a></h1>
......@@ -1096,6 +1098,11 @@ first. There is also a developer's wiki at<br/>
crash recovery. Readers can continue accessing the table. Such
tables probably cannot have indexes. One complexity is the handling
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>
</li></ul>
<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