$PostgreSQL: pgsql/src/backend/optimizer/README,v 1.45 2008/04/09 00:59:24 momjian Exp $

$PostgreSQL: pgsql/src/backend/optimizer/README,v 1.46 2008/04/0901:00:46 momjian Exp $

Optimizer

=========

1) Take each base relation in the query, and make a RelOptInfo structure

for it. Find each potentially useful way of accessing the relation,

including sequential and index scans, and makea Pathrepresentingthat

way. All the Paths made for a given relation are placed in its

including sequential and index scans, and makePathsrepresentingthose

ways. All the Paths made for a given relation are placed in its

RelOptInfo.pathlist. (Actually, we discard Paths that are obviously

inferior alternatives before they ever get into the pathlist --- what

ends up in the pathlist is the cheapest way of generating each potentially

planner()

set up for recursive handling of subqueries

do final cleanup after planning.

do final cleanup after planning

-subquery_planner()

pull up subqueries from rangetable, if possible

canonicalize qual

$PostgreSQL: pgsql/src/backend/parser/README,v 1.9 2008/04/09 00:59:24 momjian Exp $

$PostgreSQL: pgsql/src/backend/parser/README,v 1.10 2008/04/0901:00:46 momjian Exp $

Parser

======

gram.yparse the tokens and fill query-type-specific structures

analyze.ctop level of parse analysis for optimizable queries

parse_clause.chandle clauses like WHERE, ORDER BY, GROUP BY, ...

parse_coerce.chandle coercing expressions to different types

parse_coerce.chandle coercing expressions to differentdatatypes

parse_expr.chandle expressions like col, col + 3, x = 3 or x = 4

parse_oper.chandle operators in expressions

parse_agg.chandle aggregates, like SUM(col1), AVG(col2), ...

parse_func.chandle functions, table.column and column identifiers

parse_node.ccreate nodes for various structures

parse_target.chandle the result list of the query

parse_relation.c support routines for tables and column handling

parse_type.csupport routines for type handling

parse_type.csupport routines fordatatype handling

parse_utilcmd.cparse analysis for utility commands (done at execution time)

$PostgreSQL: pgsql/src/backend/utils/mmgr/README,v 1.14 2008/04/09 00:59:24 momjian Exp $

$PostgreSQL: pgsql/src/backend/utils/mmgr/README,v 1.15 2008/04/0901:00:46 momjian Exp $

Notes About Memory Allocation Redesign

======================================

Up through version 7.0, Postgres had serious problems with memory leakage

during large queries that process a lot of pass-by-reference data. There

was no provision for recycling memory until end of query. Thisneeds to be

fixed, even more so with the advent of TOAST which willallow very large

was no provision for recycling memory until end of query. Thisneeded to be

fixed, even more so with the advent of TOAST which willallowed very large

chunks of data to be passed around in the system. This document describes

the new memory managementplan implemented in 7.1.

the new memory managementsystem implemented in 7.1.

Background