Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commitd3215af

Browse files
committed
Update intro in face of TOAST.
1 parent264f8f2 commitd3215af

File tree

1 file changed

+70
-51
lines changed

1 file changed

+70
-51
lines changed

‎doc/src/sgml/lobj.sgml

Lines changed: 70 additions & 51 deletions
Original file line numberDiff line numberDiff line change
@@ -1,54 +1,74 @@
11
<!--
2-
$Header: /cvsroot/pgsql/doc/src/sgml/lobj.sgml,v 1.21 2001/09/15 16:08:59 petere Exp $
2+
$Header: /cvsroot/pgsql/doc/src/sgml/lobj.sgml,v 1.22 2001/09/16 22:53:52 petere Exp $
33
-->
44

55
<chapter id="largeObjects">
66
<title id="largeObjects-title">Large Objects</title>
77

8-
<para>
9-
In <productname>Postgres</productname>,
10-
data values are stored in tuples and
11-
individual tuples cannot span data pages. Since the size of
12-
a data page is 8192 bytes, the upper limit on the size
13-
of a data value is relatively low. To support the storage
14-
of larger atomic values,
15-
<productname>Postgres</productname> provides a large
16-
object interface. This interface provides file
17-
oriented access to user data that has been declared to
18-
be a large type.
19-
This section describes the implementation and the
20-
programming and query language interfaces to
21-
<productname>Postgres</productname>
22-
large object data.
23-
</para>
24-
25-
<sect1 id="lo-history">
26-
<title>Historical Note</title>
8+
<sect1 id="lo-intro">
9+
<title>Introduction</title>
2710

2811
<para>
29-
Originally, <productname>Postgres 4.2</productname> supported three standard
30-
implementations of large objects: as files external
31-
to <productname>Postgres</productname>, as
32-
external files managed by <productname>Postgres</productname>, and as data
33-
stored within the <productname>Postgres</productname> database. It causes
34-
considerable confusion among users. As a result, we only
35-
support large objects as data stored within the <productname>Postgres</productname>
36-
database in <productname>PostgreSQL</productname>. Even though it is slower to
37-
access, it provides stricter data integrity.
38-
For historical reasons, this storage scheme is referred to as
39-
Inversion large objects. (We will use Inversion and large
40-
objects interchangeably to mean the same thing in this
41-
section.)
42-
Since <productname>PostgreSQL 7.1</productname> all large objects are placed in
43-
one system table called <classname>pg_largeobject</classname>.
12+
In <productname>PostgreSQL</productname> releases prior to 7.1,
13+
the size of any row in the database could not exceed the size of a
14+
data page. Since the size of a data page is 8192 bytes (the
15+
default, which can be raised up to 32768), the upper limit on the
16+
size of a data value was relatively low. To support the storage of
17+
larger atomic values, <productname>PostgreSQL</productname>
18+
provided and continues to provide a large object interface. This
19+
interface provides file-oriented access to user data that has been
20+
declared to be a large object.
4421
</para>
22+
23+
<para>
24+
<productname>POSTGRES 4.2</productname>, the indirect predecessor
25+
of <productname>PostgreSQL</productname>, supported three standard
26+
implementations of large objects: as files external to the
27+
<productname>POSTGRES</productname> server, as external files
28+
managed by the <productname>POSTGRES</productname> server, and as
29+
data stored within the <productname>POSTGRES</productname>
30+
database. This caused considerable confusion among users. As a
31+
result, only support for large objects as data stored within the
32+
database is retained in <productname>PostgreSQL</productname>.
33+
Even though this is slower to access, it provides stricter data
34+
integrity. For historical reasons, this storage scheme is
35+
referred to as <firstterm>Inversion large
36+
objects</firstterm>. (You will see the term Inversion used
37+
occasionally to mean the same thing as large object.) Since
38+
<productname>PostgreSQL 7.1</productname>, all large objects are
39+
placed in one system table called
40+
<classname>pg_largeobject</classname>.
41+
</para>
42+
43+
<para>
44+
<productname>PostgreSQL 7.1</productname> introduced a mechanism
45+
(nicknamed <quote><acronym>TOAST</acronym></quote>) that allows
46+
data rows to be much larger than individual data pages. This
47+
makes the large object interface partially obsolete. One
48+
remaining advantage of the large object interface is that it
49+
allows random access to the data, i.e., the ability to read or
50+
write small chunks of a large value. It is planned to equip
51+
<acronym>TOAST</acronym> with such functionality in the future.
52+
</para>
53+
54+
<para>
55+
This section describes the implementation and the programming and
56+
query language interfaces to <productname>PostgreSQL</productname>
57+
large object data. We use the <application>libpq</application> C
58+
library for the examples in this section, but most programming
59+
interfaces native to <productname>PostgreSQL</productname> support
60+
equivalent functionality. Other interfaces may use the large
61+
object interface internally to provide generic support for large
62+
values. This is not described here.
63+
</para>
64+
4565
</sect1>
4666

4767
<sect1 id="lo-implementation">
4868
<title>Implementation Features</title>
4969

5070
<para>
51-
TheInversionlarge object implementation breaks large
71+
The large object implementation breaks large
5272
objects up into <quote>chunks</quote> and stores the chunks in
5373
tuples in the database. A B-tree index guarantees fast
5474
searches for the correct chunk number when doing random
@@ -60,27 +80,27 @@ $Header: /cvsroot/pgsql/doc/src/sgml/lobj.sgml,v 1.21 2001/09/15 16:08:59 petere
6080
<title>Interfaces</title>
6181

6282
<para>
63-
The facilities <productname>Postgres</productname> provides to
83+
The facilities <productname>PostgreSQL</productname> provides to
6484
access large objects, both in the backend as part of user-defined
6585
functions or the front end as part of an application
6686
using the interface, are described below. For users
67-
familiar with <productname>Postgres 4.2</productname>,
87+
familiar with <productname>POSTGRES 4.2</productname>,
6888
<productname>PostgreSQL</productname> has a new set of
6989
functions providing a more coherent interface.
7090

7191
<note>
7292
<para>
7393
All large object manipulation <emphasis>must</emphasis> take
7494
place within an SQL transaction. This requirement is strictly
75-
enforced as ofPostgres 6.5, though it has been an
95+
enforced as of<productname>PostgreSQL 6.5</>, though it has been an
7696
implicit requirement in previous versions, resulting in
7797
misbehavior if ignored.
7898
</para>
7999
</note>
80100
</para>
81101

82102
<para>
83-
The <productname>Postgres</productname> large object interface is modeled after
103+
The <productname>PostgreSQL</productname> large object interface is modeled after
84104
the <acronym>Unix</acronym> file system interface, with analogues of
85105
<function>open(2)</function>, <function>read(2)</function>,
86106
<function>write(2)</function>,
@@ -96,7 +116,7 @@ $Header: /cvsroot/pgsql/doc/src/sgml/lobj.sgml,v 1.21 2001/09/15 16:08:59 petere
96116
examined, by the beard function.
97117
Large objects may be accessed from dynamically-loaded <acronym>C</acronym>
98118
functions or database client programs that link the
99-
library. <productname>Postgres</productname> provides a set of routines that
119+
library. <productname>PostgreSQL</productname> provides a set of routines that
100120
support opening, reading, writing, closing, and seeking on
101121
large objects.
102122
</para>
@@ -113,18 +133,17 @@ Oid lo_creat(PGconn *<replaceable class="parameter">conn</replaceable>, int <rep
113133
<replaceable class="parameter">mode</replaceable> is a bit mask
114134
describing several different attributes of the new
115135
object. The symbolic constants listed here are defined
116-
in
117-
<filename>$<envar>PGROOT</envar>/src/backend/libpq/libpq-fs.h</filename>
136+
in the header file <filename>libpq/libpq-fs.h</filename>.
118137
The access type (read, write, or both) is controlled by
119-
OR'ing together the bits <acronym>INV_READ</acronym> and
120-
<acronym>INV_WRITE</acronym>. The low-order sixteen bits of mask are
121-
the storage manager number on which the large object
122-
should reside.For sites other than Berkeley, these
123-
bits should always be zero.
124-
The commands below createan (Inversion) large object:
125-
<programlisting>
138+
OR'ing together the bits <symbol>INV_READ</symbol> and
139+
<symbol>INV_WRITE</symbol>. The low-order sixteen bits ofthemaskhave
140+
historically been used at Berkeley to designate the storage manager number on which the large object
141+
should reside.These
142+
bits should always be zero now.
143+
The commands below createa large object:
144+
<programlisting>
126145
inv_oid = lo_creat(INV_READ|INV_WRITE);
127-
</programlisting>
146+
</programlisting>
128147
</para>
129148
</sect2>
130149

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp