88< body bgcolor ="#FFFFFF " text ="#000000 " link ="#FF0000 " vlink ="#A00000 " alink ="#0000FF ">
99< h1 > < a name ="section_1 "> PostgreSQL TODO List</ a > </ h1 >
1010< p > Current maintainer: Bruce Momjian (< a href ="mailto:pgman@candle.pha.pa.us "> pgman@candle.pha.pa.us</ a > )< br />
11- Last updated: Mon Dec 12 08:36:28 EST 2005
11+ Last updated: Fri Dec 16 13:56:52 EST 2005
1212</ p >
1313< p > The most recent version of this document can be viewed at< br />
1414< a href ="http://www.postgresql.org/docs/faqs.TODO.html "> http://www.postgresql.org/docs/faqs.TODO.html</ a > .
@@ -125,7 +125,7 @@ <h1><a name="section_2">Administration</a></h1>
125125 </ li > < li > Automatically force archiving of partially-filled WAL files when
126126 pg_stop_backup() is called or the server is stopped
127127< p > Doing this will allow administrators to know more easily when
128- the archive contins all the files needed for point-in-time
128+ the archive contains all the files needed for point-in-time
129129 recovery.
130130</ p >
131131 </ li > < li > %Create dump tool for write-ahead logs for use in determining
@@ -172,7 +172,7 @@ <h1><a name="section_4">Data Types</a></h1>
172172 </ li > < li > Fix data types where equality comparison isn't intuitive, e.g. box
173173 </ li > < li > %Prevent INET cast to CIDR if the unmasked bits are not zero, or
174174 zero the bits
175- </ li > < li > %Prevent INET cast to CIDR from droping netmask, SELECT '< a href ="telnet://1.1.1.1 "> 1.1.1.1</ a > '::inet::cidr
175+ </ li > < li > %Prevent INET cast to CIDR from dropping netmask, SELECT '< a href ="telnet://1.1.1.1 "> 1.1.1.1</ a > '::inet::cidr
176176 </ li > < li > Allow INET + INT4 to increment the host part of the address, or
177177 throw an error on overflow
178178 </ li > < li > %Add 'tid != tid ' operator for use in corruption recovery
@@ -417,7 +417,7 @@ <h1><a name="section_8">SQL Commands</a></h1>
417417 < li > Automatically maintain clustering on a table
418418< p > This might require some background daemon to maintain clustering
419419 during periods of low usage. It might also require tables to be only
420- paritally filled for easier reorganization. Another idea would
420+ partially filled for easier reorganization. Another idea would
421421 be to create a merged heap/index data file so an index lookup would
422422 automatically access the heap data too. A third idea would be to
423423 store heap rows in hashed groups, perhaps using a user-supplied
@@ -539,7 +539,7 @@ <h1><a name="section_9">Clients</a></h1>
539539 </ li > < li > Improve psql's handling of multi-line statements
540540< p > Currently, while \e saves a single statement as one entry, interactive
541541 statements are saved one line at a time. Ideally all statements
542- whould be saved like \e does.
542+ would be saved like \e does.
543543</ p >
544544 </ li > < li > Allow multi-line column values to align in the proper columns
545545< p > If the second output column value is 'a\nb', the 'b' should appear
@@ -605,10 +605,10 @@ <h1><a name="section_9">Clients</a></h1>
605605 historically it has so we need a way to prevent it
606606</ p >
607607 </ li > < li > Allow statement results to be automatically batched to the client
608- < p > Currently, all statement results are transfered to the libpq
608+ < p > Currently, all statement results are transferred to the libpq
609609 client before libpq makes the results available to the
610610 application. This feature would allow the application to make
611- use of the first result rows while the rest are transfered , or
611+ use of the first result rows while the rest are transferred , or
612612 held on the server waiting for them to be requested by libpq.
613613 One complexity is that a statement like SELECT 1/col could error
614614 out mid-way through the result set.
@@ -677,7 +677,7 @@ <h1><a name="section_12">Exotic Features</a></h1>
677677</ p >
678678 </ li > < li > Add the features of packages
679679 < ul >
680- < li > Make private objects accessable only to objects in the same schema
680+ < li > Make private objects accessible only to objects in the same schema
681681 </ li > < li > Allow current_schema.objname to access current schema objects
682682 </ li > < li > Add session variables
683683 </ li > < li > Allow nested schemas
@@ -774,7 +774,7 @@ <h1><a name="section_15">Cache Usage</a></h1>
774774 to obtain tuple visibility information.
775775</ p >
776776 </ li > < li > Add estimated_count(*) to return an estimate of COUNT(*)
777- < p > This would use the planner ANALYZE statistatics to return an estimated
777+ < p > This would use the planner ANALYZE statistics to return an estimated
778778 count.
779779</ p >
780780 </ li > < li > Allow data to be pulled directly from indexes
@@ -799,7 +799,7 @@ <h1><a name="section_15">Cache Usage</a></h1>
799799 </ li > < li > Query results
800800 </ li > </ ul >
801801 </ li > < li > Allow sequential scans to take advantage of other concurrent
802- sequentiqal scans, also called "Synchronised Scanning"
802+ sequential scans, also called "Synchronised Scanning"
803803< p > One possible implementation is to start sequential scans from the lowest
804804 numbered buffer in the shared cache, and when reaching the end wrap
805805 around to the beginning, rather than always starting sequential scans
@@ -810,7 +810,7 @@ <h1><a name="section_16">Vacuum</a></h1>
810810
811811< ul >
812812 < li > Improve speed with indexes
813- < p > For large table adjustements during VACUUM FULL, it is faster to
813+ < p > For large table adjustments during VACUUM FULL, it is faster to
814814 reindex rather than update the index.
815815</ p >
816816 </ li > < li > Reduce lock time during VACUUM FULL by moving tuples with read lock,
@@ -853,7 +853,7 @@ <h1><a name="section_18">Startup Time Improvements</a></h1>
853853 < li > Experiment with multi-threaded backend [< a href ="http://momjian.postgresql.org/cgi-bin/pgtodo?thread "> thread</ a > ]
854854< p > This would prevent the overhead associated with process creation. Most
855855 operating systems have trivial process creation time compared to
856- database startup overhead, but a few operating systems (WIn32 ,
856+ database startup overhead, but a few operating systems (Win32 ,
857857 Solaris) might benefit from threading. Also explore the idea of
858858 a single session using multiple threads to execute a statement faster.
859859</ p >
0 commit comments