From bad59c290eb92d5ca4a4b78931c123a1eb40ded8 Mon Sep 17 00:00:00 2001
From: Bruce Momjian <bruce@momjian.us>
Date: Thu, 20 Jun 2002 04:34:31 +0000
Subject: [PATCH] Add new Russian FAQ.
Viktor Vislobokov
---
doc/FAQ_russian | 48 ++++++++++++++---------------
doc/src/FAQ/FAQ_russian.html | 59 +++++++++++++++++-------------------
2 files changed, 51 insertions(+), 56 deletions(-)
diff --git a/doc/FAQ_russian b/doc/FAQ_russian
index 5de01e27ce2..45d2ea6025d 100644
--- a/doc/FAQ_russian
+++ b/doc/FAQ_russian
@@ -1,7 +1,7 @@
Ответы на часто задаваемые вопросы по PostgreSQL
- Дата последнего обновления: Вторник 26 Апреля 23:03:46 EDT 2002
+ Дата последнего обновления: Четверг 11 Июня 06:36:10 EDT 2002
Английский вариант сопровождает: Брюс Момьян (Bruce Momjian)
(pgman@candle.pha.pa.us)
@@ -105,6 +105,8 @@
4.23) Как выполнить внешнее связывание?
4.24) Как выполнять запросы, использующие несколько баз данных?
4.25) Как мне вернуть из функции несколько записей?
+ 4.26) Почему я не могу надежно создавать/удалять временные таблицы в
+ функциях PL/PgSQL?
Расширения PostgreSQL
@@ -356,34 +358,18 @@
для работы с содержимым блокировок.
Производительность
- PostgreSQL может работать в двух режима. В нормальном fsync
- режиме, каждая завершенная транзакция сбрасывается на диск,
- гарантируя, что если операционная система или питание рухнет в
- следующие несколько секунд, все ваши данные безопасно
- сохранятся на диске. В этом режиме, мы работаем медленее, чем
- большинство коммерческих СУБД, отчасти потому, что некоторые из
- них делают у себя по умолчанию такой консервативный сброс на
- диск. В режиме no-fsync, мы обычно быстрее чем коммерческие
- СУБД, но в этом режиме, падение операциооной системы может
- привести к потере данных. Мы работаем над тем чтобы
- предоставить промежуточный режим, который обеспечивал более
- высокую производительность, чем fsync режим и позволял
- сохранить целостность данных записанных в течении 30 секунд до
- падения операционной системы.
+ PostgreSQL имеет производительность схожую с другими
+ коммерческими СУБД и с СУБД с открытым исходным кодом, в
+ каких-то аспектах работая быстрее чем они, в каких-то медленее.
В сравнении с MySQL или линейными СУБД, мы медленее при
- операциях вставки/обновления, потому что мы управляем
+ операциях вставки/обновления, потому что управляем
транзакциями. И разумеется, MySQL не имеет каких-либо
- возможностей из перечисленых в секции Возможности. Мы делаем
- упор на удобстве и возможностях, но мы также продолжаем
- увеличивать производительность путем профилирования и анализа
- исходных текстов. Существует интересная страничка в Интернет,
+ возможностей из перечисленых выше, в секции Возможности. Мы
+ делаем упор на надежность и расширенные возможности, но мы
+ также продолжаем увеличивать производительность с каждым
+ выпуском. Существует интересная страничка в Интернет,
сравнивающая PostgreSQL и MySQL на
http://openacs.org/why-not-mysql.html
- Мы управляем каждым пользовательским соединением, создавая Unix
- backend процесс. Backend процессы разделяют буферы данных и
- информацию о блокировках. При наличии нескольких процессоров,
- несколько backend процессов легко могут быть запущены на разных
- процессорах.
Надежность
Мы понимали, что наша СУБД должна быть надежной или она ничего
@@ -1133,6 +1119,18 @@ SELECT *
refcursors. Смотрите
http://developer.postgresql.org/docs/postgres/plpgsql-cursors.html,
секцию 23.7.3.3.
+
+ 4.26) Почему я не могу надежно создавать/удалять временные таблицы в
+ функциях PL/PgSQL?
+
+ PL/PgSQL кэширует содержимое функции и один из негативных эффектов
+ этого состоит в том, что если функция PL/PgSQL обращается к временной
+ таблице и эта таблица позднее удаляется и пересоздается, а функция
+ затем вызывается снова, то ее вызов приведет к ошибке, потому что
+ скэшированное содержимое функции содержит указатель на старую
+ временную таблицу. Чтобы решить эту проблему, используйте EXECUTE для
+ доступа к временным таблицам в PL/PgSQL. Использование этого оператора
+ заставит запрос перегенерироваться каждый раз.
_________________________________________________________________
Расширения PostgreSQL
diff --git a/doc/src/FAQ/FAQ_russian.html b/doc/src/FAQ/FAQ_russian.html
index 259a5b07e7d..de99068802b 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>Дата последнего обновления: Вторник 26 Апреля 23:03:46 EDT 2002</P>
+ <P>Дата последнего обновления: Четверг 11 Июня 06:36:10 EDT 2002</P>
<P>Английский вариант сопровождает: Брюс Момьян (Bruce Momjian) (<A href=
"mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</A>)<BR>
@@ -138,7 +138,8 @@
<A href="#4.24">4.24</A>) Как выполнять запросы, использующие несколько
баз данных?<BR>
<A href="#4.25">4.25</A>) Как мне вернуть из функции несколько записей?<BR>
-
+ <A href="#4.26">4.26</A>) Почему я не могу надежно создавать/удалять
+ временные таблицы в функциях PL/PgSQL?<BR>
<H2 align="center">Расширения PostgreSQL</H2>
<A href="#5.1">5.1</A>) Я написал функцию определяемую пользователем.
@@ -432,34 +433,19 @@
<DT><B>Производительность</B></DT>
- <DD>PostgreSQL может работать в двух режима. В нормальном <I>fsync</I>
- режиме, каждая завершенная транзакция сбрасывается на диск,
- гарантируя, что если операционная система или питание рухнет
- в следующие несколько секунд, все ваши данные безопасно
- сохранятся на диске. В этом режиме, мы работаем медленее,
- чем большинство коммерческих СУБД, отчасти потому, что некоторые
- из них делают у себя по умолчанию такой консервативный сброс на диск.
- В режиме <I>no-fsync</I>, мы обычно быстрее чем коммерческие СУБД,
- но в этом режиме, падение операциооной системы может привести к
- потере данных. Мы работаем над тем чтобы предоставить промежуточный
- режим, который обеспечивал более высокую производительность,
- чем <I>fsync</I> режим и позволял сохранить целостность данных
- записанных в течении 30 секунд до падения операционной системы.<BR>
- <BR>
- В сравнении с MySQL или линейными СУБД, мы медленее при операциях
- вставки/обновления, потому что мы управляем транзакциями. И разумеется,
- MySQL не имеет каких-либо возможностей из перечисленых в секции
- <I>Возможности</I>. Мы делаем упор на удобстве и
- возможностях, но мы также продолжаем увеличивать производительность
- путем профилирования и анализа исходных текстов. Существует
- интересная страничка в Интернет, сравнивающая PostgreSQL и MySQL на <A href=
- "http://openacs.org/why-not-mysql.html">http://openacs.org/why-not-mysql.html</A><BR>
+ <DD>PostgreSQL имеет производительность схожую с другими коммерческими
+ СУБД и с СУБД с открытым исходным кодом, в каких-то аспектах работая
+ быстрее чем они, в каких-то медленее. В сравнении с MySQL или линейными
+ СУБД, мы медленее при операциях вставки/обновления, потому что управляем
+ транзакциями. И разумеется, MySQL не имеет каких-либо возможностей из
+ перечисленых выше, в секции <I>Возможности</I>.
+ Мы делаем упор на надежность и расширенные возможности, но мы также
+ продолжаем увеличивать производительность с каждым выпуском. Существует
+ интересная страничка в Интернет, сравнивающая PostgreSQL и MySQL на
+ <A href="http://openacs.org/why-not-mysql.html">
+
+ http://openacs.org/why-not-mysql.html</A><BR>
- <BR>
- Мы управляем каждым пользовательским соединением, создавая
- Unix backend процесс. Backend процессы разделяют буферы данных и информацию
- о блокировках. При наличии нескольких процессоров, несколько
- backend процессов легко могут быть запущены на разных процессорах.<BR>
<BR>
</DD>
@@ -1351,11 +1337,22 @@ BYTEA bytea
<H4><A name="4.25">4.25</A>) Как мне вернуть из функции несколько записей?</H4>
<P>Вы можете возвращать из функций PL/pgSQL списки результатов, используя
- <i>refcursors</i>. Смотрите <a
+ <i>refcursors</i>. Смотрите <A
href="http://developer.postgresql.org/docs/postgres/plpgsql-cursors.html">
http://developer.postgresql.org/docs/postgres/plpgsql-cursors.html,</a>
секцию 23.7.3.3.</P>
- <HR>
+
+ <H4><A name="4.26">4.26</A>) Почему я не могу надежно создавать/удалять
+ временные таблицы в функциях PL/PgSQL?</H4>
+ PL/PgSQL кэширует содержимое функции и один из негативных эффектов этого
+ состоит в том, что если функция PL/PgSQL обращается к временной таблице
+ и эта таблица позднее удаляется и пересоздается, а функция затем вызывается
+ снова, то ее вызов приведет к ошибке, потому что скэшированное содержимое
+ функции содержит указатель на старую временную таблицу. Чтобы решить эту
+ проблему, используйте <SMALL>EXECUTE</SMALL> для доступа к временным
+ таблицам в PL/PgSQL. Использование этого оператора заставит запрос
+ перегенерироваться каждый раз.
+ <HR>
<H2 align="center">Расширения PostgreSQL</H2>
--
GitLab