diff --git a/doc/TODO b/doc/TODO index fcecf0a6f40..9798c9bbdda 100644 --- a/doc/TODO +++ b/doc/TODO @@ -2,7 +2,7 @@ PostgreSQL TODO List ==================== Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us) -Last updated: Mon Dec 12 08:36:28 EST 2005 +Last updated: Fri Dec 16 13:56:52 EST 2005 The most recent version of this document can be viewed at http://www.postgresql.org/docs/faqs.TODO.html. diff --git a/doc/src/FAQ/TODO.html b/doc/src/FAQ/TODO.html index 7b86a88fb99..eeaa46a85d6 100644 --- a/doc/src/FAQ/TODO.html +++ b/doc/src/FAQ/TODO.html @@ -8,7 +8,7 @@
Current maintainer: Bruce Momjian (pgman@candle.pha.pa.us)
-Last updated: Mon Dec 12 08:36:28 EST 2005
+Last updated: Fri Dec 16 13:56:52 EST 2005
The most recent version of this document can be viewed at
http://www.postgresql.org/docs/faqs.TODO.html.
@@ -125,7 +125,7 @@ first.
Doing this will allow administrators to know more easily when - the archive contins all the files needed for point-in-time + the archive contains all the files needed for point-in-time recovery.
This might require some background daemon to maintain clustering during periods of low usage. It might also require tables to be only - paritally filled for easier reorganization. Another idea would + partially filled for easier reorganization. Another idea would be to create a merged heap/index data file so an index lookup would automatically access the heap data too. A third idea would be to store heap rows in hashed groups, perhaps using a user-supplied @@ -539,7 +539,7 @@ first.
Currently, while \e saves a single statement as one entry, interactive statements are saved one line at a time. Ideally all statements - whould be saved like \e does. + would be saved like \e does.
If the second output column value is 'a\nb', the 'b' should appear @@ -605,10 +605,10 @@ first. historically it has so we need a way to prevent it
Currently, all statement results are transfered to the libpq +
Currently, all statement results are transferred to the libpq client before libpq makes the results available to the application. This feature would allow the application to make - use of the first result rows while the rest are transfered, or + use of the first result rows while the rest are transferred, or held on the server waiting for them to be requested by libpq. One complexity is that a statement like SELECT 1/col could error out mid-way through the result set. @@ -677,7 +677,7 @@ first.
This would use the planner ANALYZE statistatics to return an estimated +
This would use the planner ANALYZE statistics to return an estimated count.
One possible implementation is to start sequential scans from the lowest numbered buffer in the shared cache, and when reaching the end wrap around to the beginning, rather than always starting sequential scans @@ -810,7 +810,7 @@ first.
For large table adjustements during VACUUM FULL, it is faster to +
For large table adjustments during VACUUM FULL, it is faster to reindex rather than update the index.
This would prevent the overhead associated with process creation. Most operating systems have trivial process creation time compared to - database startup overhead, but a few operating systems (WIn32, + database startup overhead, but a few operating systems (Win32, Solaris) might benefit from threading. Also explore the idea of a single session using multiple threads to execute a statement faster.