diff options
Diffstat (limited to 'doc/FAQ_russian')
| -rw-r--r-- | doc/FAQ_russian | 48 |
1 files changed, 23 insertions, 25 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 |