From b5ccfc216aa4065c560546f425b6e9ca7343eb8e Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Fri, 23 Aug 2002 02:53:20 +0000 Subject: Update Russian FAQ. --- doc/src/FAQ/FAQ_russian.html | 93 ++++++++++++++++++++++++++++++++++---------- 1 file changed, 73 insertions(+), 20 deletions(-) (limited to 'doc/src') 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">

Ответы на часто задаваемые вопросы по PostgreSQL

-

Дата последнего обновления: Четверг 11 Июня 06:36:10 EDT 2002

+

Дата последнего обновления: Среда 22 Августа 19:20:40 EDT 2002

Английский вариант сопровождает: Брюс Момьян (Bruce Momjian) (pgman@candle.pha.pa.us)
@@ -82,6 +82,8 @@ clients" когда пытаюсь подключиться к базе?
3.9) Что это за файлы pg_sorttempNNN.NN в моем каталоге с базой данных?
+ 3.10) Почему необходимо делать dump и restore при + обновлении выпусков PostgreSQL?

Вопросы эксплуатации

@@ -322,7 +324,7 @@

1.7) Какая последняя версия?

-

Последний выпуск PostgreSQL - это версия 7.2.

+

Последний выпуск PostgreSQL - это версия 7.2.2.

Мы планируем выпускать новые версии каждые четыре месяца.

@@ -502,8 +504,8 @@ некоторое количество ежемесячных и одноразовых расходов, которые требуют денег. Если вы или ваша компания имеет деньги, которые можно передать в помощь нашим усилиям, пожалуйста посетите страничку - http://www.pgsql.com/pg_goodies + + https://store.pgsql.com/shopping/index.php?id=1 и сделайте свой вклад.

Хотя на страничке говорится о PostgreSQL, Inc, пункт @@ -594,6 +596,9 @@

  • Embedded HTML (PHP from http://www.php.net)
    • +

    Дополнительные интерфейсы доступны по адресу + http://www.postgresql.org/interfaces.html. +

    Вопросы администрирования

    @@ -796,6 +801,25 @@ не происходить, если 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 для этого выпуска. +

    Вопросы эксплуатации

    @@ -852,12 +876,13 @@ 
         Максимальный размер базы?              неограничен (существуют базы на 60 GB)
     Максимальный размер таблицы?           16 TB
-    Максимальный размер записи?            неограничен начиная с версии 7.1
-    Максимальный размер поля?              1 GB начиная с версии 7.1
+    Максимальный размер записи?            1.6 TB
+    Максимальный размер поля?              1 GB
     Максимальное количество записей в таблице?      неограничено
     Максимальное количество колонок в таблице?    250-1600 в зависимости от типа
     Максимальное количество индексов в таблице?   неограничено
    + Разумеется, понятие "неограничено" на самом деле ограничивается доступным дисковым пространиством и размерами памяти/своппинга. Когда значения перечисленные выше неоправдано большие, может @@ -905,6 +930,10 @@

    Индексы не требуют так много, но поскольку они создаются для большого количества данных, они также могут быть велики.

    + +

    Значения NULL сохраняются в битах и поэтому они + занимают очень мало места. +

    4.7) Как мне убедиться, что существуют нужные мне таблицы, индексы, базы данных и пользователи?

    @@ -926,7 +955,7 @@ используются только если таблица больше минимального размера и запрос выбирает только маленький процент записей в таблице. Так устроено, потому что доступ к диску с применением рандомизации при сканировании - индексов иногда медленнее, чем простое чтение таблицы или ее + индексов может быть медленнее, чем простое чтение таблицы или ее последовательное сканирование.

    Чтобы определить необходимость использования индекса для какой-либо @@ -944,14 +973,32 @@ сортировкой обычно быстрее, чем поиск по индексам в большой таблице. Однако, ORDER BY часто комбинируется с LIMIT и в этом случае индекс будет использоваться, поскольку при выполнении - будет возвращаться небольшая часть таблицы.

    + будет возвращаться небольшая часть таблицы. Фактически MAX() и MIN() не + используют индексы, но индекс используется при построении запросов с + ORDER BY и LIMIT: +
    +    SELECT col
+    FROM tab
+    ORDER BY col [ DESC ]
+    LIMIT 1
+

    Когда используются операции с шаблонами, например LIKE - или ~, индексы могут быть использованы только если начало - строки-шаблона для поиска, соответствует началу искомой строки. - Следовательно, для того, чтобы использовать индексы, шаблон в - LIKE не должен начинаться на %, а в ~ - (поиск регулярного выражения) должен начинаться на ^.

    + или ~, индексы могут быть использованы в следующих случаях: +

    +

    4.9) Как посмотреть на то, как оптимизатор выполняет мой запрос?

    @@ -999,20 +1046,19 @@

    Оператор ~ производит поиск регулярного выражения, а оператор ~* производит независимый от регистра букв поиск регулярного выражения. Независимый от регистра вариант LIKE называется - ILIKE в PostgreSQL начиная с версии 7.1.

    + ILIKE.

    Независимое от регистра сравнение обычно выражается так:

         SELECT *
     FROM tab
     WHERE lower(col) = 'abc'
-
    + Эта конструкция не будет использовать стандартный индекс. Однако, если вы создадите функциональный индекс, он будет использован: 
         CREATE INDEX tabindex on tab (lower(col));
-

    4.13) Как я могу определить, что значение поля @@ -1064,6 +1110,7 @@ BYTEA bytea name TEXT ); + автоматически транслируется в: 
         CREATE SEQUENCE person_id_seq;
@@ -1073,6 +1120,7 @@ BYTEA           bytea           
     );
     CREATE UNIQUE INDEX person_id_key ON person ( id );
    + Смотрите подробности о последовательностях на странице руководства посвященной create_sequence. Вы также можете использовать каждое поле OID в записи как уникальное значение. Однако, @@ -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'); + Затем вы должны также сохранить новое значение в переменной new_id для его использования в других запросах (например таких как внешний ключ для таблицы person). Заметим, @@ -1108,6 +1157,7 @@ BYTEA bytea INSERT INTO person (name) VALUES ('Blaise Pascal'); new_id = output of "SELECT currval('person_id_seq')"; + И наконец, вы можете использовать значение OID, возращаемое из опертора INSERT чтобы увидеть значение по умолчанию, что @@ -1213,8 +1263,7 @@ BYTEA bytea

    4.18) Почему я получаю ошибку "ERROR: Memory exhausted in AllocSetAlloc()"?

    -

    Если у вас версия ниже 7.1, то обновление версии может решить эту - проблему. Также возможно, что у вас закончилась виртуальная память +

    Предположительно у вас закончилась виртуальная память или что ваше ядро имеет маленький лимит на определенные ресурсы. Попытайтесь перед запуском postmaster выполнить следующие команды:

    @@ -1222,6 +1271,7 @@ BYTEA bytea ulimit -d 262144 limit datasize 256m + В зависимости от командного интерпретатора shell, только одна из данных команд выполнится успешно, но она позволит вам установить больший сегмент данных процесса и возможно решит проблему. Эта команда @@ -1275,6 +1325,7 @@ BYTEA bytea WHERE col1 IN (SELECT col2 FROM TAB2) + на: 
     SELECT *
@@ -1282,17 +1333,19 @@ BYTEA           bytea           
     WHERE EXISTS (SELECT col2 FROM TAB2 WHERE col1 = col2)
    + Мы надеемся убрать это ограничение в будущем выпуске.

    4.23) Как мне выполнить внешнее связывание?

    -

    PostgreSQL начиная с версии 7.1 поддерживает внешнее связывание, +

    PostgreSQL поддерживает внешнее связывание, используя стандартный синтаксис SQL. Вот два примера:

         SELECT *
     FROM t1 LEFT OUTER JOIN t2 ON (t1.col = t2.col);
    - or + + или 
         SELECT *
     FROM t1 LEFT OUTER JOIN t2 USING (col);
-- 
cgit v1.2.3