database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-06-13 07:41:39 +03:00
Code Activity

Revert README cleanups.

Browse Source
This commit is contained in:
Bruce Momjian
2008-04-09 00:59:24 +00:00
parent 8cb3ad9f52
commit 4d048b7b8b
3 changed files with 11 additions and 11 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
src/backend/optimizer/README
View File

@ -1,4 +1,4 @@
$PostgreSQL: pgsql/src/backend/optimizer/README,v 1.44 2008/04/09 00:55:30 momjian Exp $ $PostgreSQL: pgsql/src/backend/optimizer/README,v 1.45 2008/04/09 00:59:24 momjian Exp $
Optimizer 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 1) Take each base relation in the query, and make a RelOptInfo structure
for it. Find each potentially useful way of accessing the relation, for it. Find each potentially useful way of accessing the relation,
including sequential and index scans, and make Paths representing those including sequential and index scans, and make a Path representing that
ways. All the Paths made for a given relation are placed in its way. All the Paths made for a given relation are placed in its
RelOptInfo.pathlist. (Actually, we discard Paths that are obviously RelOptInfo.pathlist. (Actually, we discard Paths that are obviously
inferior alternatives before they ever get into the pathlist --- what inferior alternatives before they ever get into the pathlist --- what
ends up in the pathlist is the cheapest way of generating each potentially ends up in the pathlist is the cheapest way of generating each potentially
@ -271,7 +271,7 @@ The primary entry point is planner().
planner() planner()
set up for recursive handling of subqueries set up for recursive handling of subqueries
do final cleanup after planning do final cleanup after planning.
-subquery_planner() -subquery_planner()
pull up subqueries from rangetable, if possible pull up subqueries from rangetable, if possible
canonicalize qual canonicalize qual

6
src/backend/parser/README
View File

@ -1,4 +1,4 @@
$PostgreSQL: pgsql/src/backend/parser/README,v 1.8 2008/04/09 00:55:30 momjian Exp $ $PostgreSQL: pgsql/src/backend/parser/README,v 1.9 2008/04/09 00:59:24 momjian Exp $
Parser Parser
====== ======
@ -14,7 +14,7 @@ keywords.c turn keywords into specific tokens
gram.y parse the tokens and fill query-type-specific structures gram.y parse the tokens and fill query-type-specific structures
analyze.c top level of parse analysis for optimizable queries analyze.c top level of parse analysis for optimizable queries
parse_clause.c handle clauses like WHERE, ORDER BY, GROUP BY, ... parse_clause.c handle clauses like WHERE, ORDER BY, GROUP BY, ...
parse_coerce.c handle coercing expressions to different data types parse_coerce.c handle coercing expressions to different types
parse_expr.c handle expressions like col, col + 3, x = 3 or x = 4 parse_expr.c handle expressions like col, col + 3, x = 3 or x = 4
parse_oper.c handle operators in expressions parse_oper.c handle operators in expressions
parse_agg.c handle aggregates, like SUM(col1), AVG(col2), ... 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_node.c create nodes for various structures
parse_target.c handle the result list of the query parse_target.c handle the result list of the query
parse_relation.c support routines for tables and column handling parse_relation.c support routines for tables and column handling
parse_type.c support routines for data type handling parse_type.c support routines for type handling
parse_utilcmd.c parse analysis for utility commands (done at execution time) parse_utilcmd.c parse analysis for utility commands (done at execution time)

8
src/backend/utils/mmgr/README
View File

@ -1,14 +1,14 @@
$PostgreSQL: pgsql/src/backend/utils/mmgr/README,v 1.13 2008/04/09 00:55:30 momjian Exp $ $PostgreSQL: pgsql/src/backend/utils/mmgr/README,v 1.14 2008/04/09 00:59:24 momjian Exp $
Notes About Memory Allocation Redesign Notes About Memory Allocation Redesign
====================================== ======================================
Up through version 7.0, Postgres had serious problems with memory leakage 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 during large queries that process a lot of pass-by-reference data. There
was no provision for recycling memory until end of query. This needed to be 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 allowed very large fixed, even more so with the advent of TOAST which will allow very large
chunks of data to be passed around in the system. This document describes chunks of data to be passed around in the system. This document describes
the new memory management system implemented in 7.1. the new memory management plan implemented in 7.1.
Background Background