Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
P
Postgres FD Implementation
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Analytics
Analytics
CI / CD
Repository
Value Stream
Wiki
Wiki
Snippets
Snippets
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
Abuhujair Javed
Postgres FD Implementation
Commits
0add7598
Commit
0add7598
authored
20 years ago
by
Tom Lane
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
More minor updates and copy-editing.
parent
08457504
Changes
5
Expand all
Hide whitespace changes
Inline
Side-by-side
Showing
5 changed files
with
103 additions
and
119 deletions
+103
-119
doc/src/sgml/func.sgml
doc/src/sgml/func.sgml
+46
-65
doc/src/sgml/indices.sgml
doc/src/sgml/indices.sgml
+3
-3
doc/src/sgml/mvcc.sgml
doc/src/sgml/mvcc.sgml
+5
-5
doc/src/sgml/perform.sgml
doc/src/sgml/perform.sgml
+16
-19
doc/src/sgml/typeconv.sgml
doc/src/sgml/typeconv.sgml
+33
-27
No files found.
doc/src/sgml/func.sgml
View file @
0add7598
This diff is collapsed.
Click to expand it.
doc/src/sgml/indices.sgml
View file @
0add7598
<!-- $PostgreSQL: pgsql/doc/src/sgml/indices.sgml,v 1.4
7 2003/11/29 19:51:37 pgsq
l Exp $ -->
<!-- $PostgreSQL: pgsql/doc/src/sgml/indices.sgml,v 1.4
8 2004/12/23 23:07:38 tg
l Exp $ -->
<chapter id="indexes">
<title id="indexes-title">Indexes</title>
...
...
@@ -71,7 +71,7 @@ CREATE INDEX test1_id_index ON test1 (id);
</para>
<para>
Once
the
index is created, no further intervention is required: the
Once
an
index is created, no further intervention is required: the
system will update the index when the table is modified, and it will
use the index in queries when it thinks this would be more efficient
than a sequential table scan. But you may have to run the
...
...
@@ -761,7 +761,7 @@ CREATE UNIQUE INDEX tests_success_constraint ON tests (subject, target)
</para>
<para>
It is especially fatal to use
proportionally reduced
data sets.
It is especially fatal to use
very small test
data sets.
While selecting 1000 out of 100000 rows could be a candidate for
an index, selecting 1 out of 100 rows will hardly be, because the
100 rows will probably fit within a single disk page, and there
...
...
This diff is collapsed.
Click to expand it.
doc/src/sgml/mvcc.sgml
View file @
0add7598
<!--
$PostgreSQL: pgsql/doc/src/sgml/mvcc.sgml,v 2.4
5 2004/11/15 06:32:14 neilc
Exp $
$PostgreSQL: pgsql/doc/src/sgml/mvcc.sgml,v 2.4
6 2004/12/23 23:07:38 tgl
Exp $
-->
<chapter id="mvcc">
...
...
@@ -206,9 +206,9 @@ $PostgreSQL: pgsql/doc/src/sgml/mvcc.sgml,v 2.45 2004/11/15 06:32:14 neilc Exp $
</table>
<para>
In <productname>PostgreSQL</productname>, you can
use all four
possible transaction isolation levels. Internally, there are only
two distinct isolation levels, which correspond to the levels Read
In <productname>PostgreSQL</productname>, you can
request any of the
four standard transaction isolation levels. But internally, there are
only
two distinct isolation levels, which correspond to the levels Read
Committed and Serializable. When you select the level Read
Uncommitted you really get Read Committed, and when you select
Repeatable Read you really get Serializable, so the actual
...
...
@@ -217,7 +217,7 @@ $PostgreSQL: pgsql/doc/src/sgml/mvcc.sgml,v 2.45 2004/11/15 06:32:14 neilc Exp $
define which phenomena must not happen, they do not define which
phenomena must happen. The reason that <productname>PostgreSQL</>
only provides two isolation levels is that this is the only
sensible way to map the isolation levels to the multiversion
sensible way to map the
standard
isolation levels to the multiversion
concurrency control architecture. The behavior of the available
isolation levels is detailed in the following subsections.
</para>
...
...
This diff is collapsed.
Click to expand it.
doc/src/sgml/perform.sgml
View file @
0add7598
<!--
$PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.4
8 2004/12/01 19:00:27
tgl Exp $
$PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.4
9 2004/12/23 23:07:38
tgl Exp $
-->
<chapter id="performance-tips">
...
...
@@ -78,7 +78,7 @@ $PostgreSQL: pgsql/doc/src/sgml/perform.sgml,v 1.48 2004/12/01 19:00:27 tgl Exp
estimates are converted into disk-page units using some
fairly arbitrary fudge factors. If you want to experiment with these
factors, see the list of run-time configuration parameters in
<xref linkend="runtime-config-
resource
">.)
<xref linkend="runtime-config-
query-constants
">.)
</para>
<para>
...
...
@@ -657,16 +657,6 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
point would be rolled back, so you won't be stuck with partially
loaded data.
</para>
<para>
If you are issuing a large sequence of <command>INSERT</command>
commands to bulk load some data, also consider using <xref
linkend="sql-prepare" endterm="sql-prepare-title"> to create a
prepared <command>INSERT</command> statement. Since you are
executing the same command multiple times, it is more efficient to
prepare the command once and then use <command>EXECUTE</command>
as many times as required.
</para>
</sect2>
<sect2 id="populate-copy-from">
...
...
@@ -683,12 +673,20 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
use this method to populate a table.
</para>
<para>
If you cannot use <command>COPY</command>, it may help to use <xref
linkend="sql-prepare" endterm="sql-prepare-title"> to create a
prepared <command>INSERT</command> statement, and then use
<command>EXECUTE</command> as many times as required. This avoids
some of the overhead of repeatedly parsing and planning
<command>INSERT</command>.
</para>
<para>
Note that loading a large number of rows using
<command>COPY</command> is almost always faster than using
<command>INSERT</command>, even if multiple
<command>INSERT</command> commands are batched into a single
transaction.
<command>INSERT</command>, even if <command>PREPARE</> is used and
multiple insertions are batched into a single transaction.
</para>
</sect2>
...
...
@@ -719,10 +717,10 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
<para>
Temporarily increasing the <xref linkend="guc-maintenance-work-mem">
configuration variable when
restor
ing large amounts of data can
configuration variable when
load
ing large amounts of data can
lead to improved performance. This is because when a B-tree index
is created from scratch, the existing content of the table needs
to be sorted. Allowing the
external
merge sort to use more memory
to be sorted. Allowing the merge sort to use more memory
means that fewer merge passes will be required. A larger setting for
<varname>maintenance_work_mem</varname> may also speed up validation
of foreign-key constraints.
...
...
@@ -754,8 +752,7 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse;
Whenever you have significantly altered the distribution of data
within a table, running <xref linkend="sql-analyze"
endterm="sql-analyze-title"> is strongly recommended. This
includes when bulk loading large amounts of data into
<productname>PostgreSQL</productname>. Running
includes bulk loading large amounts of data into the table. Running
<command>ANALYZE</command> (or <command>VACUUM ANALYZE</command>)
ensures that the planner has up-to-date statistics about the
table. With no statistics or obsolete statistics, the planner may
...
...
This diff is collapsed.
Click to expand it.
doc/src/sgml/typeconv.sgml
View file @
0add7598
<!--
$PostgreSQL: pgsql/doc/src/sgml/typeconv.sgml,v 1.4
2 2003/12/14 00:10:32 neilc
Exp $
$PostgreSQL: pgsql/doc/src/sgml/typeconv.sgml,v 1.4
3 2004/12/23 23:07:38 tgl
Exp $
-->
<chapter Id="typeconv">
...
...
@@ -22,8 +22,7 @@ In many cases a user will not need
to understand the details of the type conversion mechanism.
However, the implicit conversions done by <productname>PostgreSQL</productname>
can affect the results of a query. When necessary, these results
can be tailored by a user or programmer
using <emphasis>explicit</emphasis> type conversion.
can be tailored by using <emphasis>explicit</emphasis> type conversion.
</para>
<para>
...
...
@@ -43,16 +42,17 @@ has an associated data type which determines its behavior and allowed usage.
<productname>PostgreSQL</productname> has an extensible type system that is
much more general and flexible than other <acronym>SQL</acronym> implementations.
Hence, most type conversion behavior in <productname>PostgreSQL</productname>
should be governed by general rules rather than by <foreignphrase>ad hoc</> heuristics, to allow
is governed by general rules rather than by <foreignphrase>ad hoc</>
heuristics. This allows
mixed-type expressions to be meaningful even with user-defined types.
</para>
<para>
The <productname>PostgreSQL</productname> scanner/parser d
eco
des lexical
elements into only five fundamental categories: integers,
floating-point numbers, string
s,
names, and key words. Constants of most non-numeric types are first classified as
strings. The <acronym>SQL</acronym> language definition allows specifying type
names with strings, and this mechanism can be used in
The <productname>PostgreSQL</productname> scanner/parser d
ivi
des lexical
elements into only five fundamental categories: integers,
non-integer number
s,
strings, identifiers, and key words. Constants of most non-numeric types are
first classified as strings. The <acronym>SQL</acronym> language definition
allows specifying type
names with strings, and this mechanism can be used in
<productname>PostgreSQL</productname> to start the parser down the correct
path. For example, the query
...
...
@@ -79,28 +79,30 @@ parser:
<variablelist>
<varlistentry>
<term>
Operator
s
Function call
s
</term>
<listitem>
<para>
<productname>PostgreSQL</productname> allows expressions with
prefix and postfix unary (one-argument) operators,
as well as binary (two-argument) operators.
Much of the <productname>PostgreSQL</productname> type system is built around a
rich set of functions. Functions can have one or more arguments.
Since <productname>PostgreSQL</productname> permits function
overloading, the function name alone does not uniquely identify the function
to be called; the parser must select the right function based on the data
types of the supplied arguments.
</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
Function call
s
Operator
s
</term>
<listitem>
<para>
Much of the <productname>PostgreSQL</productname> type system is built around a
rich set of functions. Function calls can have one or more arguments.
Since <productname>PostgreSQL</productname> permits function
overloading, the function name alone does not uniquely identify the function
to be called; the parser must select the right function based on the data
types of the supplied arguments.
<productname>PostgreSQL</productname> allows expressions with
prefix and postfix unary (one-argument) operators,
as well as binary (two-argument) operators. Like functions, operators can
be overloaded, and so the same problem of selecting the right operator
exists.
</para>
</listitem>
</varlistentry>
...
...
@@ -125,7 +127,7 @@ with, and perhaps converted to, the types of the target columns.
Since all query results from a unionized <command>SELECT</command> statement
must appear in a single set of columns, the types of the results of each
<command>SELECT</> clause must be matched up and converted to a uniform set.
Similarly, the
branch
expressions of a <literal>CASE</> construct must be
Similarly, the
result
expressions of a <literal>CASE</> construct must be
converted to a common type so that the <literal>CASE</> expression as a whole
has a known output type. The same holds for <literal>ARRAY</> constructs.
</para>
...
...
@@ -728,12 +730,16 @@ type.
<step performance="required">
<para>
If the target is a fixed-length type (e.g., <type>char</type> or <type>varchar</type>
declared with a length) then try to find a sizing function for the target
type. A sizing function is a function of the same name as the type,
taking two arguments of which the first is that type and the second is of type
<type>integer</type>, and returning the same type. If one is found, it is applied,
passing the column's declared length as the second parameter.
Check to see if there is a sizing cast for the target type. A sizing
cast is a cast from that type to itself. If one is found in the
<structname>pg_cast</> catalog, apply it to the expression before storing
into the destination column. The implementation function for such a cast
always takes an extra parameter of type <type>integer</type>, which receives
the destination column's declared length (actually, its
<structfield>atttypmod</> value; the interpretation of
<structfield>atttypmod</> varies for different datatypes). The cast function
is responsible for applying any length-dependent semantics such as size
checking or truncation.
</para>
</step>
...
...
This diff is collapsed.
Click to expand it.
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment