> 	o Have WITH CONSTRAINTS also create constraint indexes
> 	  http://archives.postgresql.org/pgsql-patches/2007-04/msg00149.php

index types can be reliably distinguished by examining the special space
on an index page.  Per my earlier proposal, plus the realization that
there's no need for btree's vacuum cycle ID to cycle through every possible
16-bit value.  Restricting its range a little costs nearly nothing and
eliminates the possibility of collisions.
Memo to self: remember to make bitmap indexes play along with this scheme,
assuming that patch ever gets accepted.

* Simplify ability to create partitioned tables
>   http://archives.postgresql.org/pgsql-hackers/2007-04/msg00151.php

and vacuumdb.
ITAGAKI Takahiro, with minor fixes from me.

> 	o -Make CLUSTER preserve recently-dead tuples per MVCC requirements

Patch contributed by Pavan Deolasee. Along with Japanese doc
modification by Tatsuo Ishii.

> 	o -Add more logical syntax CLUSTER table USING index;

Holger Schurig

contrib/pgbuffercache.

Greg Smith

confusion.

Michael Fuhr

> * -Allow use of indexes to search for NULLs

        o -Support a smaller header for short variable-length fields

there are some corner cases where this is needed by ruleutils.c for
proper display of variables during EXPLAIN.

Teodor Sigaev, with some kibitzing from Tom Lane.

types.

Smith. Along with Japanese doc updation by Tasuo Ishii.

> This patch changes the way pgbench outputs its latency log files so that
> every transaction gets a timestamp and notes which transaction type was
> executed.  It's a one-line change that just dumps some additional
> information that was already sitting in that area of code. I also made a
> couple of documentation corrections and clarifications on some of the more
> confusing features of pgbench.
>
> It's straightforward to parse log files in this format to analyze what
> happened during the test at a higher level than was possible with the
> original format.  You can find some rough sample code to convert this
> latency format into CVS files and then into graphs at
> http://www.westnet.com/~gsmith/content/postgresql/pgbench.htm which I'll
> be expanding on once I get all my little patches sent in here.

Also tweak README.pgbench/README.pgbench_jis:
  Remove history after pgbench was added to PostgreSQL contrib module.
  Those info was not only redundant since it has already been in CVS
  log, but also incomplete.
--------------------------------------------------------------------------
The attached is a patch to optimize contrib/pgbench using new 8.3 features.

- Use DROP IF EXISTS to suppress errors for initial loadings.
- Use a combination of TRUNCATE and COPY to reduce WAL on creating
  the accounts table.

Also, there are some cosmetic changes.

- Change the output of -v option from "starting full vacuum..."
  to "starting vacuum accounts..." in reflection of the fact.
- Shape duplicated error checks into executeStatement().


There is a big performance win in "COPY with no WAL" feature.
Thanks for the efforts!
--------------------------------------------------------------------------

right, there seems precious little reason to have a pile of hand-maintained
endianness definitions in src/include/port/*.h.  Get rid of those, and make
the couple of places that used them depend on WORDS_BIGENDIAN instead.

This commit breaks any code that assumes that the mere act of forming a tuple
(without writing it to disk) does not "toast" any fields.  While all available
regression tests pass, I'm not totally sure that we've fixed every nook and
cranny, especially in contrib.

Greg Stark with some help from Tom Lane

output to match.

with errorlevel 1 is >= 1 checks failed.

of tests. Per Andrew Dunstan.

* Reduce WAL traffic so only modified values are written rather than
  entire rows
>
>   http://archives.postgresql.org/pgsql-hackers/2007-03/msg01589.php
>

installation.

    <H3 id="item3.7">3.7) What computer hardware should I use?</H3>

It removes last remaining casts inside struct definitions.
Such usage is bad practice, as it hides problems from compiler.

Reason for the cast is popular practice in some circles
to define functions as foo(MyObj *) instead of foo(PyObject *)
thus avoiding a local variable inside functions and make
direct calling easier.  As pl/python does not use such style,
the casts were unnecessary from the start.


Marko Kreen

Per Andrew Dunstan.

CONCURRENTLY.

Gregory Stark

are in their commit critical sections via flags in the ProcArray.  Checkpoint
can watch the ProcArray to determine when it's safe to proceed.  This is
a considerably better solution to the original problem of race conditions
between checkpoint and transaction commit: it speeds up commit, since there's
one less lock to fool with, and it prevents the problem of checkpoint being
delayed indefinitely when there's a constant flow of commits.  Heikki, with
some kibitzing from Tom.

> 		o -Allow PL/PythonU to return boolean rather than 1/0

Marko Kreen