New cost model for planning, incorporating a penalty for random page

accesses versus sequential accesses, a (very crude) estimate of the
effects of caching on random page accesses, and cost to evaluate WHERE-
clause expressions.  Export critical parameters for this model as SET
variables.  Also, create SET variables for the planner's enable flags
(enable_seqscan, enable_indexscan, etc) so that these can be controlled
more conveniently than via PGOPTIONS.

Planner now estimates both startup cost (cost before retrieving
first tuple) and total cost of each path, so it can optimize queries
with LIMIT on a reasonable basis by interpolating between these costs.
Same facility is a win for EXISTS(...) subqueries and some other cases.

Redesign pathkey representation to achieve a major speedup in planning
(I saw as much as 5X on a 10-way join); also minor changes in planner
to reduce memory consumption by recycling discarded Path nodes and
not constructing unnecessary lists.

Minor cleanups to display more-plausible costs in some cases in
EXPLAIN output.

Initdb forced by change in interface to index cost estimation
functions.

1 files changed, 1 insertions, 1 deletions

diff --git a/src/backend/optimizer/README b/src/backend/optimizer/README
index bbc1204395..6ca70a91f1 100644
--- a/src/backend/optimizer/README
+++ b/src/backend/optimizer/README
@@ -122,7 +122,7 @@ among other choices.  Although the jointree scanning code produces these
 potential join combinations one at a time, all the ways to produce the
 same set of joined base rels will share the same RelOptInfo, so the paths
 produced from different join combinations that produce equivalent joinrels
-will compete in add_pathlist.
+will compete in add_path.
 
 Once we have built the final join rel, we use either the cheapest path
 for it or the cheapest path with the desired ordering (if that's cheaper