It will keep track the number of pages allocated so that
vacuum could allocate twice of the previous allocation.
This will greatly reduce the total memory consumption of
vacuum.

ALLOC_BIGCHUNK_LIMIT are always allocated as separate malloc() blocks,
and are free()d immediately upon pfree().  Also, if such a chunk is enlarged
with repalloc(), translate the operation into a realloc() so as to
minimize memory usage.  Of course, these large chunks still get freed
automatically if the alloc set is reset.
I have set ALLOC_BIGCHUNK_LIMIT at 64K for now, but perhaps another
size would be better?

constant to a different type.  Not sure that this could happen in ordinary
parser usage, but it can in some new code I'm working on...

match then it tried for a self-commutative operator with the reversed input
data types.  This is pretty silly; there could never be such an operator,
except maybe in binary-compatible-type scenarios, and we have oper_inexact
for that.  Besides which, the oprsanity regress test would complain about
such an operator.  Remove nonfunctional code and simplify routine calling
convention accordingly.

case where ORDER BY and GROUP BY request the same sort order.

and fix_opids processing to a single recursive pass over the plan tree
executed at the very tail end of planning, rather than haphazardly here
and there at different places.  Now that tlist Vars do not get modified
until the very end, it's possible to get rid of the klugy var_equal and
match_varid partial-matching routines, and just use plain equal()
throughout the optimizer.  This is a step towards allowing merge and
hash joins to be done on expressions instead of only Vars ...

sort order down into planner, instead of handling it only at the very top
level of the planner.  This fixes many things.  An explicit sort is now
avoided if there is a cheaper alternative (typically an indexscan) not
only for ORDER BY, but also for the internal sort of GROUP BY.  It works
even when there is no other reason (such as a WHERE condition) to consider
the indexscan.  It works for indexes on functions.  It works for indexes
on functions, backwards.  It's just so cool...

CAUTION: I have changed the representation of SortClause nodes, therefore
THIS UPDATE BREAKS STORED RULES.  You will need to initdb.

operators (and some other places), fix rangechecks in int8 to int4
conversion (same problem we recently figured out in pg_atoi).

failed on 'field < textconstant' ...

Now SET NAMES working again...

above a Sort or Materialize node.  As far as I can tell, the only place
that actually needed that was set_tlist_references, which was being lazy
about checking to see if it had a noname node to fix or not...

combinations of query-plan-type backend options.  Good for testing
planner/optimizer.  Tedious, though.

pathkey list --- corrects misbehavior seen with multiple mergejoin clauses
mentioning same variable.

and
for src/data directories, and one minor patch for doc/README.locale.
   Please apply.

Oleg.

store all ordering information in pathkeys lists (which are now lists of
lists of PathKeyItem nodes, not just lists of lists of vars).  This was
a big win --- the code is smaller and IMHO more understandable than it
was, even though it handles more cases.  I believe the node changes will
not force an initdb for anyone; planner nodes don't show up in stored
rules.

since it's now needed in both optimizer and parser.

Patches created by Hiroki Kataoka.

Also, improve it so that it checks for multi-column constraints.
Thanks to Mark Dalphin <mdalphin@amgen.com> for reporting the problem.

l2 contained more than one entry, there would be duplicates in the output
list.  Miscellaneous code beautification in other routines, too.

commuted (ie, the index var appears on the right).  These are now handled
the same way as merge and hash join quals that need to be commuted: the
actual reversing of the clause only happens if we actually choose the path
and generate a plan from it.  Furthermore, the clause is only reversed in
the 'indexqual' field of the plan, not in the 'indxqualorig' field.  This
allows the clause to still be recognized and removed from qpquals of upper
level join plans.  Also, simplify and generalize match_clause_to_indexkey;
now it recognizes binary-compatible indexes for join as well as restriction
clauses.

contains much code that looks like it will handle indexquals with the index
key on either side of the operator, in fact indexquals must have the index
key on the left because of limitations of the ScanKey machinery.  Perhaps
someone will be motivated to fix that someday...

routines that are now dead code.

work under a wider range of scenarios than it did --- it formerly did not
handle a multi-pass inner scan, nor cases in which the inner scan's
indxqualorig or non-index qual contained outer var references.  I am not
sure that these limitations could be hit in the existing optimizer, but
they need to be fixed for future expansion.

> >
> > was implemented by Jan Wieck.
> > His work is for ascending order cases.
> >
> > Here is a patch to prevent sorting also in descending
> > order cases.
> > Because I had already changed _bt_first() to position
> > backward correctly before v6.5,this patch would work.
> >
Hiroshi Inoue
Inoue@tpf.co.jp

expression_tree_mutator.