Add new Russian FAQ.
Viktor Vislobokov
This commit is contained in:
Bruce Momjian
parent
cd75bb7011
commit
bad59c290e
doc
@ -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
|
||||
|
||||
@ -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>
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user