PostgreSQL TODO List

====================

Current maintainer:Bruce Momjian (bruce@momjian.us)

Last updated:Sat Jan13 10:13:24 EST 2007

Last updated:Tue Jan16 22:43:34 EST 2007

The most recent version of this document can be viewed at

http://www.postgresql.org/docs/faqs.TODO.html.

o %Issue log message to suggest VACUUM FULL if a table is nearly

empty?

o Consider logging activity either to the logs or a system view

o Turn on by default

http://archives.postgresql.org/pgsql-hackers/2006-08/msg01852.php

o -Turn on by default

Locking

<bodybgcolor="#FFFFFF"text="#000000"link="#FF0000"vlink="#A00000"alink="#0000FF">

<h1><aname="section_1">PostgreSQL TODO List</a></h1>

<p>Current maintainer: Bruce Momjian (<ahref="mailto:bruce@momjian.us">bruce@momjian.us</a>)<br/>

Last updated:Sat Jan13 10:13:24 EST 2007

Last updated:Tue Jan16 22:43:34 EST 2007

<p>The most recent version of this document can be viewed at<br/>

<ahref="http://www.postgresql.org/docs/faqs.TODO.html">http://www.postgresql.org/docs/faqs.TODO.html</a>.

</li><li>Add ISO day of week format 'ID' to to_char() where Monday = 1

</li><li>Add a field 'isoyear' to extract(), based on the ISO week

</li><li>Add SPI_gettypmod() to return the typemod for a TupleDesc

</li><li>Allow inlining of set-returning functions

</li><li>Implement inlining of set-returning functions defined in SQL

</li><li>Allow SQL-language functions to return results from RETURNING queries

<h1><aname="section_6">Multi-Language Support</a></h1>

<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><ahref="http://archives.postgresql.org/pgsql-hackers/2004-06/msg00168.php">http://archives.postgresql.org/pgsql-hackers/2004-06/msg00168.php</a>

</li><li>Consider sorting hash buckets so entries can be found using a

binary search, rather than a linear scan

get a count directly from a unique index, but for this to be

faster than a sequential scan it must avoid access to the heap

to obtain tuple visibility information.

</li><li>Provide a way to calculate an "estimated COUNT(*)"

<p> Perhaps by using the optimizer's cardinality estimates or random

sampling.

<p><ahref="http://archives.postgresql.org/pgsql-hackers/2005-11/msg00943.php">http://archives.postgresql.org/pgsql-hackers/2005-11/msg00943.php</a>

</li><li>Allow data to be pulled directly from indexes

<p> Currently indexes do not have enough tuple visibility information

</li><li>%Issue log message to suggest VACUUM FULL if a table is nearly

empty?

</li><li>Consider logging activity either to the logs or a system view

</li><li>Turn on by default

<p><ahref="http://archives.postgresql.org/pgsql-hackers/2006-08/msg01852.php">http://archives.postgresql.org/pgsql-hackers/2006-08/msg01852.php</a>

</li><li>-<em>Turn on by default</em>

<h1><aname="section_16">Locking</a></h1>

<li>Fix priority ordering of read and write light-weight locks (Neil)

<p><ahref="http://archives.postgresql.org/pgsql-hackers/2004-11/msg00893.php">http://archives.postgresql.org/pgsql-hackers/2004-11/msg00893.php</a>

<ahref="http://archives.postgresql.org/pgsql-hackers/2004-11/msg00905.php">http://archives.postgresql.org/pgsql-hackers/2004-11/msg00905.php</a>

<h1><aname="section_17">Startup Time Improvements</a></h1>