mirror of
https://github.com/postgres/postgres.git
synced 2025-11-01 00:05:40 -04:00
Add new Russian FAQ.
Viktor Vislobokov
This commit is contained in:
parent
cd75bb7011
commit
bad59c290e
@ -1,7 +1,7 @@
|
|||||||
|
|
||||||
Ответы на часто задаваемые вопросы по PostgreSQL
|
Ответы на часто задаваемые вопросы по PostgreSQL
|
||||||
|
|
||||||
Дата последнего обновления: Вторник 26 Апреля 23:03:46 EDT 2002
|
Дата последнего обновления: Четверг 11 Июня 06:36:10 EDT 2002
|
||||||
|
|
||||||
Английский вариант сопровождает: Брюс Момьян (Bruce Momjian)
|
Английский вариант сопровождает: Брюс Момьян (Bruce Momjian)
|
||||||
(pgman@candle.pha.pa.us)
|
(pgman@candle.pha.pa.us)
|
||||||
@ -105,6 +105,8 @@
|
|||||||
4.23) Как выполнить внешнее связывание?
|
4.23) Как выполнить внешнее связывание?
|
||||||
4.24) Как выполнять запросы, использующие несколько баз данных?
|
4.24) Как выполнять запросы, использующие несколько баз данных?
|
||||||
4.25) Как мне вернуть из функции несколько записей?
|
4.25) Как мне вернуть из функции несколько записей?
|
||||||
|
4.26) Почему я не могу надежно создавать/удалять временные таблицы в
|
||||||
|
функциях PL/PgSQL?
|
||||||
|
|
||||||
Расширения PostgreSQL
|
Расширения PostgreSQL
|
||||||
|
|
||||||
@ -356,34 +358,18 @@
|
|||||||
для работы с содержимым блокировок.
|
для работы с содержимым блокировок.
|
||||||
|
|
||||||
Производительность
|
Производительность
|
||||||
PostgreSQL может работать в двух режима. В нормальном fsync
|
PostgreSQL имеет производительность схожую с другими
|
||||||
режиме, каждая завершенная транзакция сбрасывается на диск,
|
коммерческими СУБД и с СУБД с открытым исходным кодом, в
|
||||||
гарантируя, что если операционная система или питание рухнет в
|
каких-то аспектах работая быстрее чем они, в каких-то медленее.
|
||||||
следующие несколько секунд, все ваши данные безопасно
|
|
||||||
сохранятся на диске. В этом режиме, мы работаем медленее, чем
|
|
||||||
большинство коммерческих СУБД, отчасти потому, что некоторые из
|
|
||||||
них делают у себя по умолчанию такой консервативный сброс на
|
|
||||||
диск. В режиме no-fsync, мы обычно быстрее чем коммерческие
|
|
||||||
СУБД, но в этом режиме, падение операциооной системы может
|
|
||||||
привести к потере данных. Мы работаем над тем чтобы
|
|
||||||
предоставить промежуточный режим, который обеспечивал более
|
|
||||||
высокую производительность, чем fsync режим и позволял
|
|
||||||
сохранить целостность данных записанных в течении 30 секунд до
|
|
||||||
падения операционной системы.
|
|
||||||
В сравнении с MySQL или линейными СУБД, мы медленее при
|
В сравнении с MySQL или линейными СУБД, мы медленее при
|
||||||
операциях вставки/обновления, потому что мы управляем
|
операциях вставки/обновления, потому что управляем
|
||||||
транзакциями. И разумеется, MySQL не имеет каких-либо
|
транзакциями. И разумеется, MySQL не имеет каких-либо
|
||||||
возможностей из перечисленых в секции Возможности. Мы делаем
|
возможностей из перечисленых выше, в секции Возможности. Мы
|
||||||
упор на удобстве и возможностях, но мы также продолжаем
|
делаем упор на надежность и расширенные возможности, но мы
|
||||||
увеличивать производительность путем профилирования и анализа
|
также продолжаем увеличивать производительность с каждым
|
||||||
исходных текстов. Существует интересная страничка в Интернет,
|
выпуском. Существует интересная страничка в Интернет,
|
||||||
сравнивающая PostgreSQL и MySQL на
|
сравнивающая PostgreSQL и MySQL на
|
||||||
http://openacs.org/why-not-mysql.html
|
http://openacs.org/why-not-mysql.html
|
||||||
Мы управляем каждым пользовательским соединением, создавая Unix
|
|
||||||
backend процесс. Backend процессы разделяют буферы данных и
|
|
||||||
информацию о блокировках. При наличии нескольких процессоров,
|
|
||||||
несколько backend процессов легко могут быть запущены на разных
|
|
||||||
процессорах.
|
|
||||||
|
|
||||||
Надежность
|
Надежность
|
||||||
Мы понимали, что наша СУБД должна быть надежной или она ничего
|
Мы понимали, что наша СУБД должна быть надежной или она ничего
|
||||||
@ -1133,6 +1119,18 @@ SELECT *
|
|||||||
refcursors. Смотрите
|
refcursors. Смотрите
|
||||||
http://developer.postgresql.org/docs/postgres/plpgsql-cursors.html,
|
http://developer.postgresql.org/docs/postgres/plpgsql-cursors.html,
|
||||||
секцию 23.7.3.3.
|
секцию 23.7.3.3.
|
||||||
|
|
||||||
|
4.26) Почему я не могу надежно создавать/удалять временные таблицы в
|
||||||
|
функциях PL/PgSQL?
|
||||||
|
|
||||||
|
PL/PgSQL кэширует содержимое функции и один из негативных эффектов
|
||||||
|
этого состоит в том, что если функция PL/PgSQL обращается к временной
|
||||||
|
таблице и эта таблица позднее удаляется и пересоздается, а функция
|
||||||
|
затем вызывается снова, то ее вызов приведет к ошибке, потому что
|
||||||
|
скэшированное содержимое функции содержит указатель на старую
|
||||||
|
временную таблицу. Чтобы решить эту проблему, используйте EXECUTE для
|
||||||
|
доступа к временным таблицам в PL/PgSQL. Использование этого оператора
|
||||||
|
заставит запрос перегенерироваться каждый раз.
|
||||||
_________________________________________________________________
|
_________________________________________________________________
|
||||||
|
|
||||||
Расширения PostgreSQL
|
Расширения PostgreSQL
|
||||||
|
|||||||
@ -14,7 +14,7 @@
|
|||||||
alink="#0000ff">
|
alink="#0000ff">
|
||||||
<H1>Ответы на часто задаваемые вопросы по PostgreSQL</H1>
|
<H1>Ответы на часто задаваемые вопросы по PostgreSQL</H1>
|
||||||
|
|
||||||
<P>Дата последнего обновления: Вторник 26 Апреля 23:03:46 EDT 2002</P>
|
<P>Дата последнего обновления: Четверг 11 Июня 06:36:10 EDT 2002</P>
|
||||||
|
|
||||||
<P>Английский вариант сопровождает: Брюс Момьян (Bruce Momjian) (<A href=
|
<P>Английский вариант сопровождает: Брюс Момьян (Bruce Momjian) (<A href=
|
||||||
"mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</A>)<BR>
|
"mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</A>)<BR>
|
||||||
@ -138,7 +138,8 @@
|
|||||||
<A href="#4.24">4.24</A>) Как выполнять запросы, использующие несколько
|
<A href="#4.24">4.24</A>) Как выполнять запросы, использующие несколько
|
||||||
баз данных?<BR>
|
баз данных?<BR>
|
||||||
<A href="#4.25">4.25</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>
|
<H2 align="center">Расширения PostgreSQL</H2>
|
||||||
<A href="#5.1">5.1</A>) Я написал функцию определяемую пользователем.
|
<A href="#5.1">5.1</A>) Я написал функцию определяемую пользователем.
|
||||||
@ -432,34 +433,19 @@
|
|||||||
|
|
||||||
<DT><B>Производительность</B></DT>
|
<DT><B>Производительность</B></DT>
|
||||||
|
|
||||||
<DD>PostgreSQL может работать в двух режима. В нормальном <I>fsync</I>
|
<DD>PostgreSQL имеет производительность схожую с другими коммерческими
|
||||||
режиме, каждая завершенная транзакция сбрасывается на диск,
|
СУБД и с СУБД с открытым исходным кодом, в каких-то аспектах работая
|
||||||
гарантируя, что если операционная система или питание рухнет
|
быстрее чем они, в каких-то медленее. В сравнении с MySQL или линейными
|
||||||
в следующие несколько секунд, все ваши данные безопасно
|
СУБД, мы медленее при операциях вставки/обновления, потому что управляем
|
||||||
сохранятся на диске. В этом режиме, мы работаем медленее,
|
транзакциями. И разумеется, MySQL не имеет каких-либо возможностей из
|
||||||
чем большинство коммерческих СУБД, отчасти потому, что некоторые
|
перечисленых выше, в секции <I>Возможности</I>.
|
||||||
из них делают у себя по умолчанию такой консервативный сброс на диск.
|
Мы делаем упор на надежность и расширенные возможности, но мы также
|
||||||
В режиме <I>no-fsync</I>, мы обычно быстрее чем коммерческие СУБД,
|
продолжаем увеличивать производительность с каждым выпуском. Существует
|
||||||
но в этом режиме, падение операциооной системы может привести к
|
интересная страничка в Интернет, сравнивающая PostgreSQL и MySQL на
|
||||||
потере данных. Мы работаем над тем чтобы предоставить промежуточный
|
<A href="http://openacs.org/why-not-mysql.html">
|
||||||
режим, который обеспечивал более высокую производительность,
|
|
||||||
чем <I>fsync</I> режим и позволял сохранить целостность данных
|
http://openacs.org/why-not-mysql.html</A><BR>
|
||||||
записанных в течении 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>
|
|
||||||
|
|
||||||
<BR>
|
|
||||||
Мы управляем каждым пользовательским соединением, создавая
|
|
||||||
Unix backend процесс. Backend процессы разделяют буферы данных и информацию
|
|
||||||
о блокировках. При наличии нескольких процессоров, несколько
|
|
||||||
backend процессов легко могут быть запущены на разных процессорах.<BR>
|
|
||||||
<BR>
|
<BR>
|
||||||
</DD>
|
</DD>
|
||||||
|
|
||||||
@ -1351,10 +1337,21 @@ BYTEA bytea
|
|||||||
<H4><A name="4.25">4.25</A>) Как мне вернуть из функции несколько записей?</H4>
|
<H4><A name="4.25">4.25</A>) Как мне вернуть из функции несколько записей?</H4>
|
||||||
|
|
||||||
<P>Вы можете возвращать из функций PL/pgSQL списки результатов, используя
|
<P>Вы можете возвращать из функций PL/pgSQL списки результатов, используя
|
||||||
<i>refcursors</i>. Смотрите <a
|
<i>refcursors</i>. Смотрите <A
|
||||||
href="http://developer.postgresql.org/docs/postgres/plpgsql-cursors.html">
|
href="http://developer.postgresql.org/docs/postgres/plpgsql-cursors.html">
|
||||||
http://developer.postgresql.org/docs/postgres/plpgsql-cursors.html,</a>
|
http://developer.postgresql.org/docs/postgres/plpgsql-cursors.html,</a>
|
||||||
секцию 23.7.3.3.</P>
|
секцию 23.7.3.3.</P>
|
||||||
|
|
||||||
|
<H4><A name="4.26">4.26</A>) Почему я не могу надежно создавать/удалять
|
||||||
|
временные таблицы в функциях PL/PgSQL?</H4>
|
||||||
|
PL/PgSQL кэширует содержимое функции и один из негативных эффектов этого
|
||||||
|
состоит в том, что если функция PL/PgSQL обращается к временной таблице
|
||||||
|
и эта таблица позднее удаляется и пересоздается, а функция затем вызывается
|
||||||
|
снова, то ее вызов приведет к ошибке, потому что скэшированное содержимое
|
||||||
|
функции содержит указатель на старую временную таблицу. Чтобы решить эту
|
||||||
|
проблему, используйте <SMALL>EXECUTE</SMALL> для доступа к временным
|
||||||
|
таблицам в PL/PgSQL. Использование этого оператора заставит запрос
|
||||||
|
перегенерироваться каждый раз.
|
||||||
<HR>
|
<HR>
|
||||||
|
|
||||||
<H2 align="center">Расширения PostgreSQL</H2>
|
<H2 align="center">Расширения PostgreSQL</H2>
|
||||||
|
|||||||
Loading…
x
Reference in New Issue
Block a user