Revert sentence removal from nickname in FAQ.
This commit is contained in:
parent
20c5542c8b
commit
8cb3ad9f52
@ -10,7 +10,7 @@
|
||||
alink="#0000ff">
|
||||
<H1>Frequently Asked Questions (FAQ) for PostgreSQL</H1>
|
||||
|
||||
<P>Last updated: Tue Apr 8 20:43:08 EDT 2008</P>
|
||||
<P>Last updated: Mon Mar 3 11:22:50 EST 2008</P>
|
||||
|
||||
<P>Current maintainer: Bruce Momjian (<A href=
|
||||
"mailto:bruce@momjian.us">bruce@momjian.us</A>)
|
||||
@ -150,8 +150,10 @@
|
||||
http://www.postgresql.org/docs/faqs.FAQ_DEV.html</A>
|
||||
</P>
|
||||
|
||||
<P>Postgres is a widely-used nickname for PostgreSQL. If you find
|
||||
'PostgreSQL' hard to pronounce, call it 'Postgres' instead.</P>
|
||||
<P>Postgres is a widely-used nickname for PostgreSQL. It was the
|
||||
original name of the project at Berkeley and is strongly preferred
|
||||
over other nicknames. If you find 'PostgreSQL' hard to pronounce, call
|
||||
it 'Postgres' instead.</P>
|
||||
|
||||
<H3 id="item1.2">1.2) Who controls PostgreSQL?<BR></H3>
|
||||
|
||||
|
@ -1,4 +1,4 @@
|
||||
$PostgreSQL: pgsql/src/backend/optimizer/README,v 1.43 2008/03/21 13:23:28 momjian Exp $
|
||||
$PostgreSQL: pgsql/src/backend/optimizer/README,v 1.44 2008/04/09 00:55:30 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.7 2008/03/21 13:23:28 momjian Exp $
|
||||
$PostgreSQL: pgsql/src/backend/parser/README,v 1.8 2008/04/09 00:55:30 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.12 2008/03/20 17:55:15 momjian Exp $
|
||||
$PostgreSQL: pgsql/src/backend/utils/mmgr/README,v 1.13 2008/04/09 00:55:30 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