PostgreSQL TODO List

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

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

Last updated:Mon Mar 316:26:04 EST 2008

Last updated:Mon Mar 320:33:10 EST 2008

The most recent version of this document can be viewed at

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

http://archives.postgresql.org/pgsql-hackers/2006-12/msg00255.php

* pg_dump

* pg_dump / pg_restore

o %Add dumping of comments on index columns and composite type columns

o %Add full object name to the tag field. eg. for operators we need

'=(integer, integer)', instead of just '='.

COMMENT ON CURRENT DATABASE.

o Remove unnecessary function pointer abstractions in pg_dump source

code

o Allow pg_dump to utilize multiple CPUs and I/O channels by dumping

multiple objects simultaneously

The difficulty with this is getting multiple dump processes to

produce a single dump output file.

http://archives.postgresql.org/pgsql-hackers/2008-02/msg00205.php

o Allow pg_restore to utilize multiple CPUs and I/O channels by

restoring multiple objects simultaneously

This might require a pg_restore flag to indicate how many

simultaneous operations should be performed. Only pg_dump's

-Fc format has the necessary dependency information.

o To better utilize resources, restore data, primary keys, and

indexes for a single table before restoring the next table

Hopefully this will allow the CPU-I/O load to be more uniform

for simultaneous restores. The idea is to start data restores

for several objects, and once the first object is done, to move

on to its primary keys and indexes. Over time, simultaneous

data loads and index builds will be running.

o To better utilize resources, allow pg_restore to check foreign

keys simultaneously, where possible

o Allow pg_restore to create all indexes of a table

concurrently, via a single heap scan

This requires a pg_dump -Fc file because that format contains

the required dependency information.

http://archives.postgresql.org/pgsql-general/2007-05/msg01274.php

o Allow pg_restore to load different parts of the COPY data

simultaneously

* ecpg

downtime.

* Allow multiple indexes to be created concurrently, ideally via a

single heap scan, and havea restore of a pg_dump somehow use it

single heap scan, and havepg_restore use it

http://archives.postgresql.org/pgsql-general/2007-05/msg01274.php

* Inheritance

<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: Mon Mar 316:26:04 EST 2008

Last updated: Mon Mar 320:33:10 EST 2008

<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>.

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

</li><li>pg_dump

</li><li>pg_dump / pg_restore

<li>%Add dumping of comments on index columns and composite type columns

</li><li>%Add full object name to the tag field. eg. for operators we need

COMMENT ON CURRENT DATABASE.

</li><li>Remove unnecessary function pointer abstractions in pg_dump source

code

</li><li>Allow pg_dump to utilize multiple CPUs and I/O channels by dumping

multiple objects simultaneously

<p> The difficulty with this is getting multiple dump processes to

produce a single dump output file.

<ahref="http://archives.postgresql.org/pgsql-hackers/2008-02/msg00205.php">http://archives.postgresql.org/pgsql-hackers/2008-02/msg00205.php</a>

</li><li>Allow pg_restore to utilize multiple CPUs and I/O channels by

restoring multiple objects simultaneously

<p> This might require a pg_restore flag to indicate how many

simultaneous operations should be performed. Only pg_dump's

-Fc format has the necessary dependency information.

</li><li>To better utilize resources, restore data, primary keys, and

indexes for a single table before restoring the next table

<p> Hopefully this will allow the CPU-I/O load to be more uniform

for simultaneous restores. The idea is to start data restores

for several objects, and once the first object is done, to move

on to its primary keys and indexes. Over time, simultaneous

data loads and index builds will be running.

</li><li>To better utilize resources, allow pg_restore to check foreign

keys simultaneously, where possible

</li><li>Allow pg_restore to create all indexes of a table

concurrently, via a single heap scan

<p> This requires a pg_dump -Fc file because that format contains

the required dependency information.

<ahref="http://archives.postgresql.org/pgsql-general/2007-05/msg01274.php">http://archives.postgresql.org/pgsql-general/2007-05/msg01274.php</a>

</li><li>Allow pg_restore to load different parts of the COPY data

simultaneously

</li><li>ecpg

downtime.

</li><li>Allow multiple indexes to be created concurrently, ideally via a

single heap scan, and have a restore of a pg_dump somehow use it

<p><ahref="http://archives.postgresql.org/pgsql-general/2007-05/msg01274.php">http://archives.postgresql.org/pgsql-general/2007-05/msg01274.php</a>

single heap scan, and have pg_restore use it

</li><li>Inheritance

<li>Allow inherited tables to inherit indexes, UNIQUE constraints,