o Research self-referential UPDATEs that see inconsistent row versions
          in read-committed mode


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

selecting power-of-2, rather than prime, numbers of buckets in hash joins.
If the hash functions are doing their jobs properly by making all hash bits
equally random, this is good enough, and it saves expensive integer division
and modulus operations.

delivering a well-randomized hash value.  I got religion on this after
observing that performance of multi-batch hash join degrades terribly if the
higher-order bits of hash values aren't random, as indeed was true for say
hashes of small integer values.  It's now expected and documented that hash
functions should use hash_any or some comparable method to ensure that all
bits of their output are about equally random.

initdb forced because this change invalidates existing hash indexes.  For the
same reason, this isn't back-patchable; the hash join performance problem
will get a band-aid fix in the back branches.

	http://www.ibm.com/developerworks/linux/library/l-clear-code/?ca=dgr-FClnxw01linuxcodetips

EXPLAIN-only operation was a little too short; it skipped initializing the
node's result tuple type, which may be needed depending on what's above the
indexscan node.  Call ExecAssignResultTypeFromTL before exiting.  (For good
luck I moved up the ExecAssignScanProjectionInfo call as well, so that
everything except indexscan-specific initialization will still be done.)
Per example from Grant Finnemore.

index key columns always have the type expected by the index's associated
operators, ie, we add RelabelType nodes when dealing with binary-compatible
index opclasses.  This is needed to get varchar indexes to play nicely with
the new EquivalenceClass machinery, as per recent gripe from Josh Berkus that
CVS HEAD was failing to match a varchar index column to a constant restriction
in the query.

It seems likely that this change will allow removal of a lot of ugly ad-hoc
RelabelType-stripping that the planner has traditionally done while matching
expressions to other expressions, but I'll worry about that some other day.

to implement limited-size "ring" of buffers for VACUUM for GIN & GIST

fail when used in a deferred trigger.  Bug goes back to 8.0; no doubt the
reason it hadn't been noticed is that we've been discouraging use of
user-defined constraint triggers.  Per report from Frank van Vugt.

< * Consider allowing 64-bit integers to be passed by value on 64-bit
<   platforms
> * Consider allowing 64-bit integers and floats to be passed by value on
>   64-bit platforms
>
>   Also change 32-bit floats (float4) to be passed by value at the same
>   time.
>

buffers, rather than blowing out the whole shared-buffer arena.  Aside from
avoiding cache spoliation, this fixes the problem that VACUUM formerly tended
to cause a WAL flush for every page it modified, because we had it hacked to
use only a single buffer.  Those flushes will now occur only once per
ring-ful.  The exact ring size, and the threshold for seqscans to switch into
the ring usage pattern, remain under debate; but the infrastructure seems
done.  The key bit of infrastructure is a new optional BufferAccessStrategy
object that can be passed to ReadBuffer operations; this replaces the former
StrategyHintVacuum API.

This patch also changes the buffer usage-count methodology a bit: we now
advance usage_count when first pinning a buffer, rather than when last
unpinning it.  To preserve the behavior that a buffer's lifetime starts to
decrease when it's released, the clock sweep code is modified to not decrement
usage_count of pinned buffers.

Work not done in this commit: teach GiST and GIN indexes to use the vacuum
BufferAccessStrategy for vacuum-driven fetches.

Original patch by Simon, reworked by Heikki and again by Tom.

< * Consider allowing 64-bit integers to be passed by reference on 64-bit
> * Consider allowing 64-bit integers to be passed by value on 64-bit

>
> * Consider allowing 64-bit integers to be passed by reference on 64-bit
>   platforms

Les Hill

appropriate.

Guillaume Cottenceau

in a loop.

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

Jim Nasby

directory.

Mark Cotner and David Fetter

David Fetter

"microsecond" and "millisecond" units were not considered valid input
by themselves, which caused inputs like "1 millisecond" to be rejected
erroneously.

Update the docs, add regression tests, and backport to 8.2 and 8.1

compared PortalContext with QueryContext, but the latter no longer exists.

necessary in 1997, when geqo_threshold did not exist, but it is no
longer needed.

< * Fix self-referential UPDATEs seeing inconsistent row versions in
> * Fix self-referential UPDATEs that see inconsistent row versions in

>
> * Fix self-referential UPDATEs seeing inconsistent row versions in
>   read-committed mode
>
>   http://archives.postgresql.org/pgsql-hackers/2007-05/msg00507.php

error messages when a single COPY line is too long for us to handle.  Per
example from Johann Spies.

right to think carefully about how insert and delete counts map to
n_live_tuples.  Of course a deletion should reduce n_live_tuples.

Sorry guys, I committed the file from my development snapshot instead the one from HEAD. Fixing it now.

Changed variable test to not run into infinite loops on backend errors.

or abort within a backend; rearrange InitPostgres processing to make it so.
Revealed by just-added Asserts along with ECPG regression tests (hm, I wonder
why the core regression tests didn't expose it?).  This possibly is another
reason for missing stats updates ...

and aborted transactions have different effects; also teach it not to assume
that prepared transactions are always committed.

Along the way, simplify the pgstats API by tying counting directly to
Relations; I cannot detect any redeeming social value in having stats
pointers in HeapScanDesc and IndexScanDesc structures.  And fix a few
corner cases in which counts might be missed because the relation's
pgstat_info pointer hadn't been set.

inheritance child of an UPDATE/DELETE target relation can be excluded by
constraints.  I had rearranged some code in set_append_rel_pathlist() to
avoid "useless" work when a child is excluded, but overdid it and left
the child with no cheapest_path entry, causing possible failure later
if the appendrel was involved in a join.  Also, it seems that the dummy
plan generated by inheritance_planner() when all branches are excluded
has to be a bit less dummy now than was required in 8.2.
Per report from Jan Wieck.  Add his test case to the regression tests.