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:bruce@momjian.us "> bruce@momjian.us</ a > )< br />
11- Last updated:Wed Jun18 21:15:40 EDT 2008
11+ Last updated:Mon Jun23 16:20:35 EDT 2008
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 > .
@@ -1203,7 +1203,24 @@ <h1><a name="section_12">Indexes</a></h1>
12031203</ li > < li > Allow multi-column hash indexes
12041204</ li > < li > -< em > During index creation, pre-sort the tuples to improve build speed</ em >
12051205</ li > </ ul >
1206- < h1 > < a name ="section_13 "> Fsync</ a > </ h1 >
1206+ < h1 > < a name ="section_13 "> Sorting</ a > </ h1 >
1207+ < ul >
1208+ < li > Consider using hash buckets to do DISTINCT, rather than sorting
1209+ < p > This would be beneficial when there are few distinct values. This is
1210+ already used by GROUP BY.
1211+ </ p >
1212+ </ li > < li > Consider whether duplicate keys should be sorted by block/offset
1213+ < p > < a href ="http://archives.postgresql.org/pgsql-hackers/2008-03/msg00558.php "> http://archives.postgresql.org/pgsql-hackers/2008-03/msg00558.php</ a >
1214+ </ p >
1215+ </ li > < li > -< em > Avoid tuple some tuple copying in sort routines</ em >
1216+ </ li > < li > Consider being smarter about memory and external files used during
1217+ sorts
1218+ < p > < a href ="http://archives.postgresql.org/pgsql-hackers/2007-11/msg01101.php "> http://archives.postgresql.org/pgsql-hackers/2007-11/msg01101.php</ a >
1219+ < a href ="http://archives.postgresql.org/pgsql-hackers/2007-12/msg00045.php "> http://archives.postgresql.org/pgsql-hackers/2007-12/msg00045.php</ a >
1220+ </ p >
1221+ </ li > < li > Consider detoasting keys before sorting
1222+ </ li > </ ul >
1223+ < h1 > < a name ="section_14 "> Fsync</ a > </ h1 >
12071224
12081225< ul >
12091226< li > Determine optimal fdatasync/fsync, O_SYNC/O_DSYNC options
@@ -1216,7 +1233,7 @@ <h1><a name="section_13">Fsync</a></h1>
12161233< p > < a href ="http://archives.postgresql.org/pgsql-hackers/2007-06/msg00541.php "> http://archives.postgresql.org/pgsql-hackers/2007-06/msg00541.php</ a >
12171234</ p >
12181235</ li > </ ul >
1219- < h1 > < a name ="section_14 "> Cache Usage</ a > </ h1 >
1236+ < h1 > < a name ="section_15 "> Cache Usage</ a > </ h1 >
12201237
12211238< ul >
12221239< li > Speed up COUNT(*)
@@ -1277,7 +1294,7 @@ <h1><a name="section_14">Cache Usage</a></h1>
12771294< p > < a href ="http://archives.postgresql.org/pgsql-hackers/2007-11/msg00562.php "> http://archives.postgresql.org/pgsql-hackers/2007-11/msg00562.php</ a >
12781295</ p >
12791296</ li > </ ul >
1280- < h1 > < a name ="section_15 "> Vacuum</ a > </ h1 >
1297+ < h1 > < a name ="section_16 "> Vacuum</ a > </ h1 >
12811298
12821299< ul >
12831300< li > Improve speed with indexes
@@ -1345,7 +1362,7 @@ <h1><a name="section_15">Vacuum</a></h1>
13451362</ p >
13461363</ li > </ ul >
13471364</ li > </ ul >
1348- < h1 > < a name ="section_16 "> Locking</ a > </ h1 >
1365+ < h1 > < a name ="section_17 "> Locking</ a > </ h1 >
13491366
13501367< ul >
13511368< li > Fix priority ordering of read and write light-weight locks (Neil)
@@ -1375,7 +1392,7 @@ <h1><a name="section_16">Locking</a></h1>
13751392< p > < a href ="http://archives.postgresql.org/pgsql-hackers/2008-01/msg00873.php "> http://archives.postgresql.org/pgsql-hackers/2008-01/msg00873.php</ a >
13761393</ p >
13771394</ li > </ ul >
1378- < h1 > < a name ="section_17 "> Startup Time Improvements</ a > </ h1 >
1395+ < h1 > < a name ="section_18 "> Startup Time Improvements</ a > </ h1 >
13791396
13801397< ul >
13811398< li > Experiment with multi-threaded backend for backend creation
@@ -1386,7 +1403,7 @@ <h1><a name="section_17">Startup Time Improvements</a></h1>
13861403 a single session using multiple threads to execute a statement faster.
13871404</ p >
13881405</ li > </ ul >
1389- < h1 > < a name ="section_18 "> Write-Ahead Log</ a > </ h1 >
1406+ < h1 > < a name ="section_19 "> Write-Ahead Log</ a > </ h1 >
13901407
13911408< ul >
13921409< li > Eliminate need to write full pages to WAL before page modification
@@ -1469,7 +1486,7 @@ <h1><a name="section_18">Write-Ahead Log</a></h1>
14691486< p > < a href ="http://archives.postgresql.org/pgsql-hackers/2007-11/msg00035.php "> http://archives.postgresql.org/pgsql-hackers/2007-11/msg00035.php</ a >
14701487</ p >
14711488</ li > </ ul >
1472- < h1 > < a name ="section_19 "> Optimizer / Executor</ a > </ h1 >
1489+ < h1 > < a name ="section_20 "> Optimizer / Executor</ a > </ h1 >
14731490
14741491< ul >
14751492< li > Improve selectivity functions for geometric operators
@@ -1480,10 +1497,6 @@ <h1><a name="section_19">Optimizer / Executor</a></h1>
14801497 actual row counts differ by a specified percentage
14811498</ li > < li > Improve how ANALYZE computes in-doubt tuples
14821499< p > < a href ="http://archives.postgresql.org/pgsql-hackers/2007-11/msg00771.php "> http://archives.postgresql.org/pgsql-hackers/2007-11/msg00771.php</ a >
1483- </ p >
1484- </ li > < li > Consider using hash buckets to do DISTINCT, rather than sorting
1485- < p > This would be beneficial when there are few distinct values. This is
1486- already used by GROUP BY.
14871500</ p >
14881501</ li > < li > Log statements where the optimizer row estimates were dramatically
14891502 different from the number of rows actually found?
@@ -1498,7 +1511,7 @@ <h1><a name="section_19">Optimizer / Executor</a></h1>
14981511< p > < a href ="http://archives.postgresql.org/pgsql-hackers/2007-05/msg00450.php "> http://archives.postgresql.org/pgsql-hackers/2007-05/msg00450.php</ a >
14991512</ p >
15001513</ li > </ ul >
1501- < h1 > < a name ="section_20 "> Background Writer</ a > </ h1 >
1514+ < h1 > < a name ="section_21 "> Background Writer</ a > </ h1 >
15021515
15031516< ul >
15041517< li > Consider having the background writer update the transaction status
@@ -1522,7 +1535,7 @@ <h1><a name="section_20">Background Writer</a></h1>
15221535< p > < a href ="http://archives.postgresql.org/pgsql-patches/2007-06/msg00340.php "> http://archives.postgresql.org/pgsql-patches/2007-06/msg00340.php</ a >
15231536</ p >
15241537</ li > </ ul >
1525- < h1 > < a name ="section_21 "> Miscellaneous Performance</ a > </ h1 >
1538+ < h1 > < a name ="section_22 "> Miscellaneous Performance</ a > </ h1 >
15261539
15271540< ul >
15281541< li > Do async I/O for faster random read-ahead of data
@@ -1608,27 +1621,21 @@ <h1><a name="section_21">Miscellaneous Performance</a></h1>
16081621</ li > < li > Sort large UPDATE/DELETEs so it is done in heap order
16091622< p > < a href ="http://archives.postgresql.org/pgsql-hackers/2008-01/msg01119.php "> http://archives.postgresql.org/pgsql-hackers/2008-01/msg01119.php</ a >
16101623</ p >
1611- </ li > < li > -< em > Avoid tuple some tuple copying in sort routines</ em >
16121624</ li > < li > SMP scalability improvements
16131625< p > < a href ="http://archives.postgresql.org/pgsql-hackers/2007-07/msg00439.php "> http://archives.postgresql.org/pgsql-hackers/2007-07/msg00439.php</ a >
16141626< a href ="http://archives.postgresql.org/pgsql-hackers/2007-09/msg00206.php "> http://archives.postgresql.org/pgsql-hackers/2007-09/msg00206.php</ a >
16151627< a href ="http://archives.postgresql.org/pgsql-hackers/2008-03/msg00361.php "> http://archives.postgresql.org/pgsql-hackers/2008-03/msg00361.php</ a >
16161628</ p >
16171629</ li > < li > Research reducing deTOASTing in more places
16181630< p > < a href ="http://archives.postgresql.org/pgsql-hackers/2007-09/msg00895.php "> http://archives.postgresql.org/pgsql-hackers/2007-09/msg00895.php</ a >
1619- </ p >
1620- </ li > < li > Consider being smarter about memory and external files used during
1621- sorts
1622- < p > < a href ="http://archives.postgresql.org/pgsql-hackers/2007-11/msg01101.php "> http://archives.postgresql.org/pgsql-hackers/2007-11/msg01101.php</ a >
1623- < a href ="http://archives.postgresql.org/pgsql-hackers/2007-12/msg00045.php "> http://archives.postgresql.org/pgsql-hackers/2007-12/msg00045.php</ a >
16241631</ p >
16251632</ li > < li > Allow one transaction to see tuples using the snapshot of another
16261633 transaction
16271634< p > This would assist multiple backends in working together.
16281635< a href ="http://archives.postgresql.org/pgsql-hackers/2008-01/msg00400.php "> http://archives.postgresql.org/pgsql-hackers/2008-01/msg00400.php</ a >
16291636</ p >
16301637</ li > </ ul >
1631- < h1 > < a name ="section_22 "> Source Code</ a > </ h1 >
1638+ < h1 > < a name ="section_23 "> Source Code</ a > </ h1 >
16321639
16331640< ul >
16341641< li > Add use of 'const' for variables in source tree
@@ -1653,7 +1660,6 @@ <h1><a name="section_22">Source Code</a></h1>
16531660< p > < a href ="http://archives.postgresql.org/pgsql-hackers/2006-09/msg02238.php "> http://archives.postgresql.org/pgsql-hackers/2006-09/msg02238.php</ a >
16541661< a href ="http://archives.postgresql.org/pgsql-patches/2006-10/msg00048.php "> http://archives.postgresql.org/pgsql-patches/2006-10/msg00048.php</ a >
16551662</ p >
1656- </ li > < li > Consider detoasting keys before sorting
16571663</ li > < li > Consider GnuTLS if OpenSSL license becomes a problem
16581664< p > < a href ="http://archives.postgresql.org/pgsql-patches/2006-05/msg00040.php "> http://archives.postgresql.org/pgsql-patches/2006-05/msg00040.php</ a >
16591665< a href ="http://archives.postgresql.org/pgsql-hackers/2006-12/msg01213.php "> http://archives.postgresql.org/pgsql-hackers/2006-12/msg01213.php</ a >
@@ -1749,7 +1755,7 @@ <h1><a name="section_22">Source Code</a></h1>
17491755 of result sets using new statement protocol
17501756</ li > </ ul >
17511757</ li > </ ul >
1752- < h1 > < a name ="section_23 "> Exotic Features</ a > </ h1 >
1758+ < h1 > < a name ="section_24 "> Exotic Features</ a > </ h1 >
17531759
17541760< ul >
17551761< li > Add pre-parsing phase that converts non-ISO syntax to supported
@@ -1777,7 +1783,7 @@ <h1><a name="section_23">Exotic Features</a></h1>
17771783< p > < a href ="http://archives.postgresql.org/pgsql-hackers/2008-01/msg00893.php "> http://archives.postgresql.org/pgsql-hackers/2008-01/msg00893.php</ a >
17781784</ p >
17791785</ li > </ ul >
1780- < h1 > < a name ="section_24 "> Features We Do< u > Not</ u > Want</ a > </ h1 >
1786+ < h1 > < a name ="section_25 "> Features We Do< u > Not</ u > Want</ a > </ h1 >
17811787
17821788< ul >
17831789< li > All backends running as threads in a single process (not wanted)