Small wording improvements for source code READMEs.
This commit is contained in:
parent
4d048b7b8b
commit
91509e6a87
@ -1,4 +1,4 @@
|
||||
$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/09 01:00:46 momjian Exp $
|
||||
|
||||
Optimizer
|
||||
=========
|
||||
@ -73,8 +73,8 @@ tree is found by a recursive process:
|
||||
|
||||
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 make a Path representing that
|
||||
way. All the Paths made for a given relation are placed in its
|
||||
including sequential and index scans, and make Paths representing those
|
||||
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
|
||||
@ -271,7 +271,7 @@ The primary entry point is planner().
|
||||
|
||||
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
|
||||
|
@ -1,4 +1,4 @@
|
||||
$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/09 01:00:46 momjian Exp $
|
||||
|
||||
Parser
|
||||
======
|
||||
@ -14,7 +14,7 @@ keywords.c turn keywords into specific tokens
|
||||
gram.y parse the tokens and fill query-type-specific structures
|
||||
analyze.c top level of parse analysis for optimizable queries
|
||||
parse_clause.c handle clauses like WHERE, ORDER BY, GROUP BY, ...
|
||||
parse_coerce.c handle coercing expressions to different types
|
||||
parse_coerce.c handle coercing expressions to different data types
|
||||
parse_expr.c handle expressions like col, col + 3, x = 3 or x = 4
|
||||
parse_oper.c handle operators in expressions
|
||||
parse_agg.c handle aggregates, like SUM(col1), AVG(col2), ...
|
||||
@ -22,5 +22,5 @@ parse_func.c handle functions, table.column and column identifiers
|
||||
parse_node.c create nodes for various structures
|
||||
parse_target.c handle the result list of the query
|
||||
parse_relation.c support routines for tables and column handling
|
||||
parse_type.c support routines for type handling
|
||||
parse_type.c support routines for data type handling
|
||||
parse_utilcmd.c parse analysis for utility commands (done at execution time)
|
||||
|
@ -1,14 +1,14 @@
|
||||
$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/09 01: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. This needs to be
|
||||
fixed, even more so with the advent of TOAST which will allow very large
|
||||
was no provision for recycling memory until end of query. This needed to be
|
||||
fixed, even more so with the advent of TOAST which will allowed very large
|
||||
chunks of data to be passed around in the system. This document describes
|
||||
the new memory management plan implemented in 7.1.
|
||||
the new memory management system implemented in 7.1.
|
||||
|
||||
|
||||
Background
|
||||
|
Loading…
x
Reference in New Issue
Block a user