From b5ccfc216aa4065c560546f425b6e9ca7343eb8e Mon Sep 17 00:00:00 2001
From: Bruce Momjian <bruce@momjian.us>
Date: Fri, 23 Aug 2002 02:53:20 +0000
Subject: [PATCH] Update Russian FAQ.
---
doc/FAQ_russian | 81 +++++++++++++++++++++++--------
doc/src/FAQ/FAQ_russian.html | 93 ++++++++++++++++++++++++++++--------
2 files changed, 133 insertions(+), 41 deletions(-)
diff --git a/doc/FAQ_russian b/doc/FAQ_russian
index 45d2ea6025d..8273e70945f 100644
--- a/doc/FAQ_russian
+++ b/doc/FAQ_russian
@@ -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);
diff --git a/doc/src/FAQ/FAQ_russian.html b/doc/src/FAQ/FAQ_russian.html
index de99068802b..744e522a2c4 100644
--- a/doc/src/FAQ/FAQ_russian.html
+++ b/doc/src/FAQ/FAQ_russian.html
@@ -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>
+
Разумеется, понятие "неограничено" на самом деле ограничивается
доступным дисковым пространиством и размерами памяти/своппинга.
Когда значения перечисленные выше неоправдано большие, может
@@ -905,6 +930,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);
--
GitLab