* Improve speed with indexes

  For large table adjustments during VACUUM FULL, it is faster to cluster
  or reindex rather than update the index.  Also, index updates can bloat
  the index.


>   http://archives.postgresql.org/pgsql-hackers/2007-08/msg00307.php

>
> * Allow domains to be cast
>
>   http://archives.postgresql.org/pgsql-hackers/2003-06/msg01206.php
>   http://archives.postgresql.org/pgsql-hackers/2007-08/msg00289.php

>
> * Consider simplifying how memory context resets handle child contexts
>
>   http://archives.postgresql.org/pgsql-patches/2007-08/msg00067.php

>   http://archives.postgresql.org/pgsql-hackers/2007-08/msg00082.php

* Consider increasing NUM_CLOG_BUFFERS

>   http://archives.postgresql.org/pgsql-performance/2007-08/msg00024.php

* Consider increasing NUM_CLOG_BUFFERS
>
>   http://archives.postgresql.org/pgsql-hackers/2007-08/msg00030.php
>

	test=> \copy billing_data from ../BillingSamplePricerFile.csv with csv
	   header quote as '"' null as 'abc' null as '123'
	\copy: parse error at "null"

Per report from Stephen Frost

        o Allow COPY in CSV mode to control whether a quoted zero-length
          string is treated as NULL

          Currently this is always treated as a zero-length string,
          which generates an error when loading into an integer column

>
> 	o Allow COPY in CSV mode to control whether "" is treated as NULL
>
> 	  http://archives.postgresql.org/pgsql-hackers/2007-07/msg00905.php

>
> 	o Improve logic of determining if an identifier is a a
> 	  variable or column name
>
> 	  http://archives.postgresql.org/pgsql-hackers/2007-07/msg00436.php

>
> * Add automated check for invalid C++ source code constructs
>
>   http://archives.postgresql.org/pgsql-patches/2007-07/msg00056.php

> * Research use of signals and sleep wake ups
>
>   http://archives.postgresql.org/pgsql-hackers/2007-07/msg00003.php

* Test to see if calling PreallocXlogFiles() from the background writer
  will help with WAL segment creation latency

  http://archives.postgresql.org/pgsql-patches/2007-06/msg00340.php

> * Consider adding buffers the background writer finds reusable to the
>   free list
>
> * Consider wither increasing BM_MAX_USAGE_COUNT improves performance
>
>   http://archives.postgresql.org/pgsql-hackers/2007-06/msg01007.php

* Reduce storage space for small NUMERICs

>   http://archives.postgresql.org/pgsql-hackers/2007-06/msg00715.php

before it goes groveling through the ProcArray.  In situations where the same
recently-committed transaction ID is checked repeatedly by tqual.c, this saves
a lot of shared-memory searches.  And it's cheap enough that it shouldn't
hurt noticeably when it doesn't help.
Concept and patch by Simon, some minor tweaking and comment-cleanup by Tom.

> 	o Consider normalizing fractions in postgresql.conf, perhaps
> 	  using '%'
>
> 	  http://archives.postgresql.org/pgsql-hackers/2007-06/msg00550.php

> * Consider sorting writes during checkpoint
>
>   http://archives.postgresql.org/pgsql-hackers/2007-06/msg00541.php

>
> * Prefix command-line utilities like createuser with 'pg_'
>
>   http://archives.postgresql.org/pgsql-hackers/2007-06/msg00025.php

>
> * Change memory allocation for multi-byte functions so memory is
>   allocated inside conversion functions
>
>   Currently we preallocate memory based on worst-case usage.

* Consider increasing the number of default statistics target, and
  reduce statistics target overhead

  Also consider having a larger statistics target for indexed columns
  and expression indexes
<
>   http://archives.postgresql.org/pgsql-general/2007-06/msg00542.php

* Consider increasing the number of default statistics target, and
  reduce statistics target overhead

  Also consider having a larger statistics target for indexed columns
  and expression indexes
>   http://archives.postgresql.org/pgsql-general/2007-05/msg01228.php
>

>
> * Consider increasing the number of default statistics target, and
>   reduce statistics target overhead
>
>   Also consider having a larger statistics target for indexed columns
>   and expression indexes

>
> * Consider using a hash for joining to a large IN (VALUES ...) list
>
>   http://archives.postgresql.org/pgsql-hackers/2007-05/msg00450.php

>
> * Consider a more compact data representation for dead tuples
>
>   http://archives.postgresql.org/pgsql-patches/2007-05/msg00143.php

* Fix problem when multiple subtransactions of the same outer transaction
  hold different types of locks, and one subtransaction aborts

>   http://archives.postgresql.org/pgsql-hackers/2007-05/msg00773.php

>
> * Add temporal versions of generate_series()
>
>   http://archives.postgresql.org/pgsql-hackers/2007-04/msg01180.php

o Review handling of MOVE and FETCH


http://archives.postgresql.org/pgsql-patches/2007-04/msg00527.php

> 	o Prevent pg_dump/pg_restore from being affected by
> 	  statement_timeout
>
> 	  Using psql to restore a pg_dump dump is also affected.

+         Setting <varname>statement_timeout</> in
+         <filename>postgresql.conf</> is not recommended because it
+         affects all sessions.

Backpatch to 8.3.X.

> * Allow statistics last vacuum/analyze execution times to be displayed
>   without requiring stats_row_level to be enabled

<
< 	o Set up autovacuum to ignore statement_timeout set in
< 	  postgresql.conf
<
< 	  http://archives.postgresql.org/pgsql-hackers/2007-03/msg01753.php

>
> * Consider adding buffers the BGW finds reusable to the free list
>
>   http://archives.postgresql.org/pgsql-hackers/2007-04/msg00781.php
>
> * Automatically tune bgwriter_delay based on activity rather then using a
>   fixed interval
>
>   http://archives.postgresql.org/pgsql-hackers/2007-04/msg00781.php

because it affects all sessions, including autovacuum.

>
> 	o Set up autovacuum to ignore statement_timeout set in
> 	  postgresql.conf
>
> 	  http://archives.postgresql.org/pgsql-hackers/2007-03/msg01753.php

* Optimize referential integrity checks

>   http://archives.postgresql.org/pgsql-hackers/2007-04/msg00744.php

* Allow administrators to safely terminate individual sessions either
  via an SQL function or SIGTERM

>   http://archives.postgresql.org/pgsql-hackers/2007-04/msg00218.php

This prevents compiler optimizations that assume overflow won't occur, which
breaks numerous overflow tests that we need to have working.  It is known
that gcc 4.3 causes problems and possible that 4.1 does.  Per my proposal
of some time ago and a recent report from Kris Jurka.

Backpatch as far as 8.0, which is as far as the patch conveniently goes.
7.x was pretty short of overflow tests anyway, so it may not matter there,
even assuming that anyone cares whether 7.x builds on recent gcc.

than dividing them into 1GB segments as has been our longtime practice.  This
requires working support for large files in the operating system; at least for
the time being, it won't be the default.

Zdenek Kotala