mirror of https://github.com/postgres/postgres
Update Russian FAQ.
This commit is contained in:
Bruce Momjian
parent
3d801dbb1c
commit
b5ccfc216a
|
|
@ -1,7 +1,7 @@
|
|||
|
||||
Ответы на часто задаваемые вопросы по PostgreSQL
|
||||
|
||||
Дата последнего обновления: Четверг 11 Июня 06:36:10 EDT 2002
|
||||
Дата последнего обновления: Среда 22 Августа 19:20:40 EDT 2002
|
||||
|
||||
Английский вариант сопровождает: Брюс Момьян (Bruce Momjian)
|
||||
(pgman@candle.pha.pa.us)
|
||||
|
|
@ -61,6 +61,8 @@
|
|||
пытаюсь подключиться к базе?
|
||||
3.9) Что это за файлы pg_sorttempNNN.NN в моем каталоге с базой
|
||||
данных?
|
||||
3.10) Почему необходимо делать dump и restore при обновлении выпусков
|
||||
PostgreSQL?
|
||||
|
||||
Вопросы эксплуатации
|
||||
|
||||
|
|
@ -267,7 +269,7 @@
|
|||
|
||||
1.7) Какая последняя версия?
|
||||
|
||||
Последний выпуск PostgreSQL - это версия 7.2.
|
||||
Последний выпуск PostgreSQL - это версия 7.2.2.
|
||||
|
||||
Мы планируем выпускать новые версии каждые четыре месяца.
|
||||
|
||||
|
|
@ -414,7 +416,7 @@
|
|||
некоторое количество ежемесячных и одноразовых расходов, которые
|
||||
требуют денег. Если вы или ваша компания имеет деньги, которые можно
|
||||
передать в помощь нашим усилиям, пожалуйста посетите страничку
|
||||
http://www.pgsql.com/pg_goodies и сделайте свой вклад.
|
||||
https://store.pgsql.com/shopping/index.php?id=1 и сделайте свой вклад.
|
||||
|
||||
Хотя на страничке говорится о PostgreSQL, Inc, пункт "contributions"
|
||||
предназначен исключительно для поддержки проекта PostgreSQL и не
|
||||
|
|
@ -478,6 +480,9 @@
|
|||
* TCL (libpgtcl)
|
||||
* C Easy API (libpgeasy)
|
||||
* Embedded HTML (PHP from http://www.php.net)
|
||||
|
||||
Дополнительные интерфейсы доступны по адресу
|
||||
http://www.postgresql.org/interfaces.html.
|
||||
_________________________________________________________________
|
||||
|
||||
Вопросы администрирования
|
||||
|
|
@ -660,6 +665,22 @@
|
|||
происходить, если backend процесс падает во время сортировки. Если у
|
||||
вас не запущено ни одного backend процесса, то вы можете спокойно
|
||||
удалить файлы pg_tempNNN.NN.
|
||||
3.10) Почему необходимо делать dump и restore при обновлении выпусков
|
||||
PostgreSQL?
|
||||
|
||||
Разработчики PostgreSQL делают только небольшие изменения между
|
||||
подвыпусками. Таким образом обновление с версии 7.2 до 7.2.1 не
|
||||
требует выполнения dump и restore. Однако при выходе очередного
|
||||
выпуска часто меняется внутренний формат системных таблиц и файлов
|
||||
данных. Эти изменения часто носят комплексный характер, так что нет
|
||||
возможности обеспечить обратную совместимость файлов данных. Выполение
|
||||
dump позволяет получить данные в общем формате, который затем может
|
||||
быть загружен при использовании нового внутреннего формата.
|
||||
|
||||
В тех выпусках, где формат данных на диске не меняется, для проведения
|
||||
обновления может быть использован сценарий pg_upgrade без
|
||||
использования dump/restore. Комментарии к выпуску говорит когда можно
|
||||
использовать pg_upgrade для этого выпуска.
|
||||
_________________________________________________________________
|
||||
|
||||
Вопросы эксплуатации
|
||||
|
|
@ -707,8 +728,8 @@
|
|||
Максимальный размер базы? неограничен (существуют базы на 60 G
|
||||
B)
|
||||
Максимальный размер таблицы? 16 TB
|
||||
Максимальный размер записи? неограничен начиная с версии 7.1
|
||||
Максимальный размер поля? 1 GB начиная с версии 7.1
|
||||
Максимальный размер записи? 1.6 TB
|
||||
Максимальный размер поля? 1 GB
|
||||
Максимальное количество записей в таблице? неограничено
|
||||
Максимальное количество колонок в таблице? 250-1600 в зависимости от тип
|
||||
а
|
||||
|
|
@ -759,6 +780,9 @@ B)
|
|||
Индексы не требуют так много, но поскольку они создаются для большого
|
||||
количества данных, они также могут быть велики.
|
||||
|
||||
Значения NULL сохраняются в битах и поэтому они занимают очень мало
|
||||
места.
|
||||
|
||||
4.7) Как мне убедиться, что существуют нужные мне таблицы, индексы, базы
|
||||
данных и пользователи?
|
||||
|
||||
|
|
@ -779,7 +803,7 @@ B)
|
|||
используются только если таблица больше минимального размера и запрос
|
||||
выбирает только маленький процент записей в таблице. Так устроено,
|
||||
потому что доступ к диску с применением рандомизации при сканировании
|
||||
индексов иногда медленнее, чем простое чтение таблицы или ее
|
||||
индексов может быть медленнее, чем простое чтение таблицы или ее
|
||||
последовательное сканирование.
|
||||
|
||||
Чтобы определить необходимость использования индекса для какой-либо
|
||||
|
|
@ -796,13 +820,30 @@ B)
|
|||
обычно быстрее, чем поиск по индексам в большой таблице. Однако, ORDER
|
||||
BY часто комбинируется с LIMIT и в этом случае индекс будет
|
||||
использоваться, поскольку при выполнении будет возвращаться небольшая
|
||||
часть таблицы.
|
||||
часть таблицы. Фактически MAX() и MIN() не используют индексы, но
|
||||
индекс используется при построении запросов с ORDER BY и LIMIT:
|
||||
SELECT col
|
||||
FROM tab
|
||||
ORDER BY col [ DESC ]
|
||||
LIMIT 1
|
||||
|
||||
Когда используются операции с шаблонами, например LIKE или ~, индексы
|
||||
могут быть использованы только если начало строки-шаблона для поиска,
|
||||
соответствует началу искомой строки. Следовательно, для того, чтобы
|
||||
использовать индексы, шаблон в LIKE не должен начинаться на %, а в ~
|
||||
(поиск регулярного выражения) должен начинаться на ^.
|
||||
могут быть использованы в следующих случаях:
|
||||
* Начало строки поиска должно совпадать с началом искомой строки,
|
||||
т.е.:
|
||||
|
||||
* LIKE шаблоны не должны начинаться с %.
|
||||
*
|
||||
* ~ шаблоны регулярных выражений должна начинаться на ^.
|
||||
*
|
||||
|
||||
Строка поиска не должна начинаться с символа класса, т.е. [a-e].
|
||||
|
||||
Не должен использоваться поиск независимый от регистра такой как
|
||||
ILIKE и ~. Вместо него используйте функциональные индексы, которые
|
||||
описаны в этом FAQ ниже.
|
||||
|
||||
Во время initdb должна использоваться локаль по умолчанию C.
|
||||
|
||||
4.9) Как посмотреть на то, как оптимизатор выполняет мой запрос?
|
||||
|
||||
|
|
@ -845,8 +886,7 @@ B)
|
|||
|
||||
Оператор ~ производит поиск регулярного выражения, а оператор ~*
|
||||
производит независимый от регистра букв поиск регулярного выражения.
|
||||
Независимый от регистра вариант LIKE называется ILIKE в PostgreSQL
|
||||
начиная с версии 7.1.
|
||||
Независимый от регистра вариант LIKE называется ILIKE.
|
||||
|
||||
Независимое от регистра сравнение обычно выражается так:
|
||||
SELECT *
|
||||
|
|
@ -1014,10 +1054,9 @@ BYTEA bytea
|
|||
|
||||
4.18) Почему я получаю ошибку "ERROR: Memory exhausted in AllocSetAlloc()"?
|
||||
|
||||
Если у вас версия ниже 7.1, то обновление версии может решить эту
|
||||
проблему. Также возможно, что у вас закончилась виртуальная память или
|
||||
что ваше ядро имеет маленький лимит на определенные ресурсы.
|
||||
Попытайтесь перед запуском postmaster выполнить следующие команды:
|
||||
Предположительно у вас закончилась виртуальная память или что ваше
|
||||
ядро имеет маленький лимит на определенные ресурсы. Попытайтесь перед
|
||||
запуском postmaster выполнить следующие команды:
|
||||
ulimit -d 262144
|
||||
limit datasize 256m
|
||||
|
||||
|
|
@ -1075,12 +1114,12 @@ SELECT *
|
|||
|
||||
4.23) Как мне выполнить внешнее связывание?
|
||||
|
||||
PostgreSQL начиная с версии 7.1 поддерживает внешнее связывание,
|
||||
используя стандартный синтаксис SQL. Вот два примера:
|
||||
PostgreSQL поддерживает внешнее связывание, используя стандартный
|
||||
синтаксис SQL. Вот два примера:
|
||||
SELECT *
|
||||
FROM t1 LEFT OUTER JOIN t2 ON (t1.col = t2.col);
|
||||
|
||||
or
|
||||
или
|
||||
SELECT *
|
||||
FROM t1 LEFT OUTER JOIN t2 USING (col);
|
||||
|
||||
|
|
|
|||
|
|
@ -14,7 +14,7 @@
|
|||
alink="#0000ff">
|
||||
<H1>Ответы на часто задаваемые вопросы по PostgreSQL</H1>
|
||||
|
||||
<P>Дата последнего обновления: Четверг 11 Июня 06:36:10 EDT 2002</P>
|
||||
<P>Дата последнего обновления: Среда 22 Августа 19:20:40 EDT 2002</P>
|
||||
|
||||
<P>Английский вариант сопровождает: Брюс Момьян (Bruce Momjian) (<A href=
|
||||
"mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</A>)<BR>
|
||||
|
|
@ -82,6 +82,8 @@
|
|||
clients"</I> когда пытаюсь подключиться к базе?<BR>
|
||||
<A href="#3.9">3.9</A>) Что это за файлы <I>pg_sorttempNNN.NN</I>
|
||||
в моем каталоге с базой данных?<BR>
|
||||
<A href="#3.10">3.10</A>) Почему необходимо делать dump и restore при
|
||||
обновлении выпусков PostgreSQL?<BR>
|
||||
|
||||
|
||||
<H2 align="center">Вопросы эксплуатации</H2>
|
||||
|
|
@ -322,7 +324,7 @@
|
|||
|
||||
<H4><A name="1.7">1.7</A>) Какая последняя версия?</H4>
|
||||
|
||||
<P>Последний выпуск PostgreSQL - это версия 7.2.</P>
|
||||
<P>Последний выпуск PostgreSQL - это версия 7.2.2.</P>
|
||||
|
||||
<P>Мы планируем выпускать новые версии каждые четыре месяца.</P>
|
||||
|
||||
|
|
@ -502,8 +504,8 @@
|
|||
некоторое количество ежемесячных и одноразовых расходов, которые
|
||||
требуют денег. Если вы или ваша компания имеет деньги, которые
|
||||
можно передать в помощь нашим усилиям, пожалуйста посетите страничку
|
||||
<A href=
|
||||
"http://www.pgsql.com/pg_goodies">http://www.pgsql.com/pg_goodies</A>
|
||||
<A href="https://store.pgsql.com/shopping/index.php?id=1">
|
||||
https://store.pgsql.com/shopping/index.php?id=1</A>
|
||||
и сделайте свой вклад.</P>
|
||||
|
||||
<P>Хотя на страничке говорится о PostgreSQL, Inc, пункт
|
||||
|
|
@ -594,6 +596,9 @@
|
|||
<LI>Embedded <SMALL>HTML</SMALL> (<A href=
|
||||
"http://www.php.net">PHP from http://www.php.net</A>)</LI>
|
||||
</UL>
|
||||
<P>Дополнительные интерфейсы доступны по адресу <A href="http://www.postgresql.org/interfaces.html">
|
||||
http://www.postgresql.org/interfaces.html.</A>
|
||||
</P>
|
||||
<HR>
|
||||
|
||||
<H2 align="center">Вопросы администрирования</H2>
|
||||
|
|
@ -796,6 +801,25 @@
|
|||
не происходить, если backend процесс падает во время сортировки.
|
||||
Если у вас не запущено ни одного backend процесса, то вы можете
|
||||
спокойно удалить файлы pg_tempNNN.NN.</P>
|
||||
|
||||
<A name="3.10">3.10</A>) Почему необходимо делать dump и restore при
|
||||
обновлении выпусков PostgreSQL?<BR>
|
||||
|
||||
<P>Разработчики PostgreSQL делают только небольшие изменения между
|
||||
подвыпусками. Таким образом обновление с версии 7.2 до 7.2.1 не требует
|
||||
выполнения dump и restore. Однако при выходе очередного выпуска часто
|
||||
меняется внутренний формат системных таблиц и файлов данных. Эти
|
||||
изменения часто носят комплексный характер, так что нет возможности
|
||||
обеспечить обратную совместимость файлов данных. Выполение dump
|
||||
позволяет получить данные в общем формате, который затем может быть
|
||||
загружен при использовании нового внутреннего формата.</P>
|
||||
|
||||
<P>
|
||||
В тех выпусках, где формат данных на диске не меняется, для проведения
|
||||
обновления может быть использован сценарий <i>pg_upgrade</i> без
|
||||
использования dump/restore. Комментарии к выпуску говорит когда можно
|
||||
использовать <i>pg_upgrade</i> для этого выпуска.
|
||||
</P>
|
||||
<HR>
|
||||
|
||||
<H2 align="center">Вопросы эксплуатации</H2>
|
||||
|
|
@ -852,12 +876,13 @@
|
|||
<PRE>
|
||||
Максимальный размер базы? неограничен (существуют базы на 60 GB)
|
||||
Максимальный размер таблицы? 16 TB
|
||||
Максимальный размер записи? неограничен начиная с версии 7.1
|
||||
Максимальный размер поля? 1 GB начиная с версии 7.1
|
||||
Максимальный размер записи? 1.6 TB
|
||||
Максимальный размер поля? 1 GB
|
||||
Максимальное количество записей в таблице? неограничено
|
||||
Максимальное количество колонок в таблице? 250-1600 в зависимости от типа
|
||||
Максимальное количество индексов в таблице? неограничено
|
||||
</PRE>
|
||||
|
||||
Разумеется, понятие "неограничено" на самом деле ограничивается
|
||||
доступным дисковым пространиством и размерами памяти/своппинга.
|
||||
Когда значения перечисленные выше неоправдано большие, может
|
||||
|
|
@ -906,6 +931,10 @@
|
|||
<P>Индексы не требуют так много, но поскольку они создаются для
|
||||
большого количества данных, они также могут быть велики.</P>
|
||||
|
||||
<P>Значения <small>NULL</small> сохраняются в битах и поэтому они
|
||||
занимают очень мало места.
|
||||
</P>
|
||||
|
||||
<H4><A name="4.7">4.7</A>) Как мне убедиться, что существуют нужные мне
|
||||
таблицы, индексы, базы данных и пользователи?</H4>
|
||||
|
||||
|
|
@ -926,7 +955,7 @@
|
|||
используются только если таблица больше минимального размера и запрос
|
||||
выбирает только маленький процент записей в таблице. Так устроено,
|
||||
потому что доступ к диску с применением рандомизации при сканировании
|
||||
индексов иногда медленнее, чем простое чтение таблицы или ее
|
||||
индексов может быть медленнее, чем простое чтение таблицы или ее
|
||||
последовательное сканирование.</P>
|
||||
|
||||
<P>Чтобы определить необходимость использования индекса для какой-либо
|
||||
|
|
@ -944,14 +973,32 @@
|
|||
сортировкой обычно быстрее, чем поиск по индексам в большой таблице.
|
||||
Однако, <SMALL>ORDER BY</SMALL> часто комбинируется с <SMALL>LIMIT</SMALL>
|
||||
и в этом случае индекс будет использоваться, поскольку при выполнении
|
||||
будет возвращаться небольшая часть таблицы.</P>
|
||||
будет возвращаться небольшая часть таблицы. Фактически MAX() и MIN() не
|
||||
используют индексы, но индекс используется при построении запросов с
|
||||
<SMALL>ORDER BY</SMALL> и <SMALL>LIMIT</SMALL>:
|
||||
<pre>
|
||||
SELECT col
|
||||
FROM tab
|
||||
ORDER BY col [ DESC ]
|
||||
LIMIT 1
|
||||
</pre>
|
||||
|
||||
<P>Когда используются операции с шаблонами, например <SMALL>LIKE</SMALL>
|
||||
или <I>~</I>, индексы могут быть использованы только если начало
|
||||
строки-шаблона для поиска, соответствует началу искомой строки.
|
||||
Следовательно, для того, чтобы использовать индексы, шаблон в
|
||||
<SMALL>LIKE</SMALL> не должен начинаться на <I>%</I>, а в <I>~</I>
|
||||
(поиск регулярного выражения) должен начинаться на <I>^</I>.</P>
|
||||
или <I>~</I>, индексы могут быть использованы в следующих случаях:
|
||||
</P><UL>
|
||||
<LI>Начало строки поиска должно совпадать с началом искомой строки, т.е.:</LI>
|
||||
<UL>
|
||||
<LI><small>LIKE</small> шаблоны не должны начинаться с <i>%.</i><LI>
|
||||
<LI><i>~</i> шаблоны регулярных выражений должна начинаться на <i>^.</i><LI>
|
||||
</UL>
|
||||
<LI>Строка поиска не должна начинаться с символа класса, т.е. [a-e].</LI>
|
||||
<LI>Не должен использоваться поиск независимый от регистра такой как
|
||||
<small>ILIKE</small> и <i>~</i>. Вместо него используйте функциональные
|
||||
индексы, которые описаны в этом FAQ ниже.</LI>
|
||||
<LI>Во время <i>initdb</i> должна использоваться локаль по умолчанию
|
||||
<i>C</i>.
|
||||
</UL>
|
||||
<p>
|
||||
|
||||
<H4><A name="4.9">4.9</A>) Как посмотреть на то, как оптимизатор выполняет
|
||||
мой запрос?</H4>
|
||||
|
|
@ -999,20 +1046,19 @@
|
|||
<P>Оператор <I>~</I> производит поиск регулярного выражения, а оператор
|
||||
<I>~*</I> производит независимый от регистра букв поиск регулярного
|
||||
выражения. Независимый от регистра вариант <SMALL>LIKE</SMALL> называется
|
||||
<SMALL>ILIKE</SMALL> в PostgreSQL начиная с версии 7.1.</P>
|
||||
<SMALL>ILIKE</SMALL>.</P>
|
||||
|
||||
<P>Независимое от регистра сравнение обычно выражается так:</P>
|
||||
<PRE>
|
||||
SELECT *
|
||||
FROM tab
|
||||
WHERE lower(col) = 'abc'
|
||||
|
||||
</PRE>
|
||||
|
||||
Эта конструкция не будет использовать стандартный индекс. Однако, если
|
||||
вы создадите функциональный индекс, он будет использован:
|
||||
<PRE>
|
||||
CREATE INDEX tabindex on tab (lower(col));
|
||||
|
||||
</PRE>
|
||||
|
||||
<H4><A name="4.13">4.13</A>) Как я могу определить, что значение поля
|
||||
|
|
@ -1064,6 +1110,7 @@ BYTEA bytea
|
|||
name TEXT
|
||||
);
|
||||
</PRE>
|
||||
|
||||
автоматически транслируется в:
|
||||
<PRE>
|
||||
CREATE SEQUENCE person_id_seq;
|
||||
|
|
@ -1073,6 +1120,7 @@ BYTEA bytea
|
|||
);
|
||||
CREATE UNIQUE INDEX person_id_key ON person ( id );
|
||||
</PRE>
|
||||
|
||||
Смотрите подробности о последовательностях на странице руководства
|
||||
посвященной <I>create_sequence</I>. Вы также можете использовать
|
||||
каждое поле <I>OID</I> в записи как уникальное значение. Однако,
|
||||
|
|
@ -1093,6 +1141,7 @@ BYTEA bytea
|
|||
new_id = output of "SELECT nextval('person_id_seq')"
|
||||
INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal');
|
||||
</PRE>
|
||||
|
||||
Затем вы должны также сохранить новое значение в переменной
|
||||
<CODE>new_id</CODE> для его использования в других запросах (например
|
||||
таких как внешний ключ для таблицы <CODE>person</CODE>). Заметим,
|
||||
|
|
@ -1108,6 +1157,7 @@ BYTEA bytea
|
|||
INSERT INTO person (name) VALUES ('Blaise Pascal');
|
||||
new_id = output of "SELECT currval('person_id_seq')";
|
||||
</PRE>
|
||||
|
||||
И наконец, вы можете использовать значение
|
||||
<A href="#4.16"><SMALL>OID</SMALL></A>, возращаемое из опертора
|
||||
<SMALL>INSERT</SMALL> чтобы увидеть значение по умолчанию, что
|
||||
|
|
@ -1213,8 +1263,7 @@ BYTEA bytea
|
|||
<H4><A name="4.18">4.18</A>) Почему я получаю ошибку <I>"ERROR: Memory
|
||||
exhausted in AllocSetAlloc()"</I>?</H4>
|
||||
|
||||
<P>Если у вас версия ниже 7.1, то обновление версии может решить эту
|
||||
проблему. Также возможно, что у вас закончилась виртуальная память
|
||||
<P>Предположительно у вас закончилась виртуальная память
|
||||
или что ваше ядро имеет маленький лимит на определенные ресурсы.
|
||||
Попытайтесь перед запуском <I>postmaster</I> выполнить следующие
|
||||
команды:</P>
|
||||
|
|
@ -1222,6 +1271,7 @@ BYTEA bytea
|
|||
ulimit -d 262144
|
||||
limit datasize 256m
|
||||
</PRE>
|
||||
|
||||
В зависимости от командного интерпретатора shell, только одна из данных
|
||||
команд выполнится успешно, но она позволит вам установить больший
|
||||
сегмент данных процесса и возможно решит проблему. Эта команда
|
||||
|
|
@ -1275,6 +1325,7 @@ BYTEA bytea
|
|||
WHERE col1 IN (SELECT col2 FROM TAB2)
|
||||
</CODE>
|
||||
</PRE>
|
||||
|
||||
на:
|
||||
<PRE>
|
||||
<CODE>SELECT *
|
||||
|
|
@ -1282,17 +1333,19 @@ BYTEA bytea
|
|||
WHERE EXISTS (SELECT col2 FROM TAB2 WHERE col1 = col2)
|
||||
</CODE>
|
||||
</PRE>
|
||||
|
||||
Мы надеемся убрать это ограничение в будущем выпуске.
|
||||
|
||||
<H4><A name="4.23">4.23</A>) Как мне выполнить внешнее связывание?</H4>
|
||||
|
||||
<P>PostgreSQL начиная с версии 7.1 поддерживает внешнее связывание,
|
||||
<P>PostgreSQL поддерживает внешнее связывание,
|
||||
используя стандартный синтаксис SQL. Вот два примера:</P>
|
||||
<PRE>
|
||||
SELECT *
|
||||
FROM t1 LEFT OUTER JOIN t2 ON (t1.col = t2.col);
|
||||
</PRE>
|
||||
or
|
||||
|
||||
или
|
||||
<PRE>
|
||||
SELECT *
|
||||
FROM t1 LEFT OUTER JOIN t2 USING (col);
|
||||
|
|
|
|||
Loading…
Reference in New Issue