* Experiment with multi-threaded backend better I/O utilization

  This would allow a single query to make use of multiple I/O channels
  simultaneously.  One idea is to create a background reader that can
  pre-fetch sequential and index scan pages needed by other backends.
  This could be expanded to allow concurrent reads from multiple devices
  in a partitioned table.

* Experiment with multi-threaded backend better CPU utilization

  This would allow several CPUs to be used for a single query, such as
  for sorting or query execution.

* Speed WAL recovery by allowing more than one page to be prefetched

  This should be done utilizing the same infrastructure used for
  prefetching in general to avoid introducing complex error-prone code
  in WAL replay.

are declared to return set, and consist of just a single SELECT.  We
can replace the FROM-item with a sub-SELECT and then optimize much as
if we were dealing with a view.  Patch from Richard Rowell, cleaned up
by me.

>
> * Consider not storing a NULL bitmap on disk if all the NULLs are
>   trailing
>
>   http://archives.postgresql.org/pgsql-hackers/2007-12/msg00624.php
>   http://archives.postgresql.org/pgsql-patches/2007-12/msg00109.php
>

errors in any commands, including in various clean targets that have so far
been handled inconsistently.  make -i is available to ignore all errors in
a consistent and official way.

on developer.postgresql.org is going away.

        o Allow UPDATE tab SET ROW (col, ...) = (SELECT...)

> 	  http://archives.postgresql.org/pgsql-patches/2007-04/msg00315.php
> 	  http://archives.postgresql.org/pgsql-patches/2008-03/msg00237.php

* Speed WAL recovery by allowing more than one page to be prefetched

  This involves having a separate process that can be told which pages
  the recovery process will need in the near future.

>   http://archives.postgresql.org/pgsql-general/2007-12/msg00683.php
>   http://archives.postgresql.org/pgsql-hackers/2007-12/msg00497.php
<

during a bitmap index scan.  This cannot affect the query results
(since we're just dumping the TIDs into a bitmap) but it might offer
some advantage in locality of access to the index.  Per Greg Stark.

> 	o Recreate pg_xlog/archive_status/ if it doesn't exist after
> 	  restoring from a PITR backup
>
> 	  http://archives.postgresql.org/pgsql-hackers/2007-12/msg00487.php

value for a precision is negative, act as though precision weren't
specified at all, that is the whole .* part of the format spec should
be ignored.  Our previous coding took it as .0 which is certainly
wrong.  Per report from Kris Jurka and local testing.

Possibly this should be back-patched, but it would be good to get
some more testing first; in any case there are no known cases where
there's really a problem on the backend side.

>
> * Consider Cartesian joins when both relations are needed to form an
>   indexscan qualification for a third relation
>
>   http://archives.postgresql.org/pgsql-performance/2007-12/msg00090.php

        o Allow COPY to report error lines and continue

          This requires the use of a savepoint before each COPY line is
          processed, with ROLLBACK on COPY failure.
> 	  http://archives.postgresql.org/pgsql-hackers/2007-12/msg00572.php

>
> * Allow SSL key file permission checks to be optionally disabled when
>   sharing SSL keys with other applications
>
>   http://archives.postgresql.org/pgsql-bugs/2007-12/msg00069.php

>
> * Reduce BIT data type overhead using short varlena headers
>
>   http://archives.postgresql.org/pgsql-general/2007-12/msg00273.php

> * Reduce file system activity overhead of statistics file pgstat.stat
>
>   http://archives.postgresql.org/pgsql-general/2007-12/msg00106.php
>

> * Consider if CommandCounterIncrement() can avoid its
>   AcceptInvalidationMessages() call
>
>   http://archives.postgresql.org/pgsql-committers/2007-11/msg00585.php

* Add SQL:2003 WITH RECURSIVE (hierarchical) queries to SELECT

>   http://archives.postgresql.org/pgsql-hackers/2007-11/msg01334.php

>
> 	o Remove pre-7.3 pg_dump code that assumes pg_depend does not exit

* Improve text search error messages

>   http://archives.postgresql.org/pgsql-hackers/2007-11/msg01146.php

> * Improve text search error messages
>
>   http://archives.postgresql.org/pgsql-hackers/2007-10/msg00966.php
>
>
> * Fix /contrib/ltree operator
>
>   http://archives.postgresql.org/pgsql-bugs/2007-11/msg00044.php

>
> 	o Fix server restart problem when the server was shutdown during
> 	  a PITR backup
>
> 	  http://archives.postgresql.org/pgsql-hackers/2007-11/msg00800.php
>

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

>   http://archives.postgresql.org/pgsql-hackers/2008-01/msg01066.php

support DTrace in the future.

Switch from using DTRACE_PROBEn macros to the dynamically generated macros.
Use "dtrace -h" to create a header file that contains the dynamically
generated macros to be used in the source code instead of the DTRACE_PROBEn
macros.  A dummy header file is generated for builds without DTrace support.

Author: Robert Lor <Robert.Lor@sun.com>

changed in case a new file got added.

>
> 	o Allow Kerberos to disable stripping of realms so we can
> 	  check the username@realm against multiple realms
>
> 	  http://archives.postgresql.org/pgsql-hackers/2007-11/msg00009.php

While at it, rename option lookup functions to make names clearer, per
discussion with Tom.

make_greater_string needs the < procedure not the >= one.  Spotted by
Peter.

needed anywhere after my previous patch.  Noticed by Tom Lane.

Also, remove #include <signal.h> from sinval.c.

oprofile shows that a nontrivial amount of time is being spent in
repeated calls to index_getprocinfo, which really only needs to be
called once.  So do that, and inline _hash_datum2hashkey to make it
work.

linear search when checking child-transaction XIDs.  This makes for an
important speedup in transactions that have large numbers of children,
as in a recent example from Craig Ringer.  We can also get rid of an
ugly kluge that represented lists of TransactionIds as lists of OIDs.

Heikki Linnakangas

> 	o -During index creation, pre-sort the tuples to improve build speed

maintenance_work_mem and effective_cache_size on index creation speed.