diff options
| -rw-r--r-- | doc/FAQ_russian | 65 | ||||
| -rw-r--r-- | doc/src/FAQ/FAQ_russian.html | 55 |
2 files changed, 59 insertions, 61 deletions
diff --git a/doc/FAQ_russian b/doc/FAQ_russian index 6ee32387cf9..bb37457726c 100644 --- a/doc/FAQ_russian +++ b/doc/FAQ_russian @@ -1,7 +1,7 @@ Otvety na chasto zadavaemye voprosy po PostgreSQL - Data poslednego obnovleniya: Subbota 7 fevralya 22:16:21 EDT 2004 + Data poslednego obnovleniya: Voskresenie 11 aprelya 23:28:03 EDT 2004 Anglijskij variant soprovozhdaet: Bryus Mom'yan (Bruce Momjian) (pgman@candle.pha.pa.us) @@ -114,7 +114,7 @@ Rasshireniya PostgreSQL 5.1) YA napisal funkciyu opredelyaemuyu pol'zovatelem. Kogda ya - zapuskayu ee v psql, pochemu ya poluchayu dump core? + zapuskayu ee v psql, pochemu ya poluchayu core dump? 5.2) Kak ya mogu vnesti nekotorye klassnye novye tipy i funkcii v PostgreSQL? 5.3) Kak mne napisat' C funkciyu, vozvraschayuschuyu zapis'? @@ -138,7 +138,7 @@ Razrabotku PostgreSQL vypolnyaet komanda razrabotchikov, vse uchastniki kotoroj podpisany na spisok rassylki razrabotchikov. V - nastoyaschee vremya, ih koordinatorom yavlyaetsya Mark Fornaj (Marc G. + nastoyaschee vremya, ih koordinatorom yavlyaetsya Mark Furn'e (Marc G. Fournier) (scrappy@PostgreSQL.org). (Sm. sekciyu 1.6 o tom, kak podklyuchit'sya k razrabotke). `Eta komanda teper' otvechaet za vsyu razrabotku PostgreSQL. Dannyj proekt yavlyaetsya obschestvennym i ne @@ -286,7 +286,7 @@ 1.7) Kakaya poslednyaya versiya? - Poslednij vypusk PostgreSQL - `eto versiya 7.4.1 + Poslednij vypusk PostgreSQL - `eto versiya 7.4.2 My planiruem vypuskat' novye versii kazhdye 6-8 mesyacev. @@ -370,18 +370,17 @@ Vozmozhnosti PostgreSQL imeet bol'shinstvo vozmozhnostej predstavlennyh v bol'shih kommercheskih SUBD, takie kak: tranzakcii, podzaprosy, - triggery, obzory (views), vneshnij klyuch ssylochnoj - celostnosti i raznye blokirovki. U nas est' nekotorye - vozmozhnosti, kotoryh net u nih: tipy, opredelyaemye - pol'zovatelem, mehanizm nasledovaniya, pravila i konkuretnoe - mnogoversionnoe upravlenie dlya raboty s soderzhimym - blokirovok. + triggery, predstavleniya, ssylochnoj celostnosti vtorichnogo + klyucha i raznye blokirovki. U nas est' nekotorye vozmozhnosti, + kotoryh net u nih: tipy, opredelyaemye pol'zovatelem, mehanizm + nasledovaniya, pravila i konkuretnoe mnogoversionnoe upravlenie + dlya raboty s soderzhimym blokirovok. Proizvoditel'nost' PostgreSQL imeet proizvoditel'nost' shozhuyu s drugimi kommercheskimi SUBD i s SUBD s otkrytym ishodnym kodom, v kakih-to aspektah rabotaya bystree chem oni, v kakih-to - medlenee. V sravnenii s MySQL ili linejnymi SUBD, my bystree, + medlenee. V sravnenii s MySQL ili obydennee SUBD, my bystree, kogda pol'zovatelej mnogo, a takzhe na kompleksnyh zaprosah i chtenii/zapisi zagruzki zaprosa. MySQL bystree dlya prostyh SELECT zaprosov, vypolnyaemyh nebol'shim kolichestvom @@ -432,7 +431,7 @@ PostgreSQL imeet odnorangovuyu infrastrukturu s togo samogo vremeni kak my nachali razrabotku v 1996 godu. My dolzhny blagodarit' za `eto - Marka Fonaya (Marc Fournier), kotoryj sozdal `etu infrastrukturu i + Marka Furn'e (Marc Fournier), kotoryj sozdal `etu infrastrukturu i upravlyaet ej na protyazhenii `etih let. Kachestvennaya infrastruktura ochen' vazhna dlya proektov s otkrytym @@ -749,7 +748,7 @@ chtoby `eta programma vydavala zaprosy, kotorye ona ispol'zuet dlya vypolneniya zadannyh vami komand. - 4.4) Kak udalit' kolonku iz tablicy ili izmenit' ioio tip dannyh? + 4.4) Kak udalit' kolonku iz tablicy ili izmenit' eio tip dannyh? DROP COLUMN funkcional'nost' byla dobavlena v vypusk 7.3 s operatorom ALTER TABLE DROP COLUMN. V rannih versiyah, mozhno sdelat' tak: @@ -773,15 +772,15 @@ dalit' 4.5) Kakovy maksimal'nye razmery dlya zapisej, tablic i bazy dannyh? Suschestvuyut sleduyuschie ogranicheniya: - Maksimal'nyj razmer bazy? neogranichen (suschestvuyut bazy na -32 TB) - Maksimal'nyj razmer tablicy? 32 TB - Maksimal'nyj razmer zapisi? 1.6 TB - Maksimal'nyj razmer polya? 1 GB - Maksimal'noe kolichestvo zapisej v tablice? neogranicheno - Maksimal'noe kolichestvo kolonok v tablice? 250-1600 v zavisimosti ot ti -pa - Maksimal'noe kolichestvo indeksov v tablice? neogranicheno + Maksimal'nyj razmer bazy? neogranichen (suschestvuyut ba +zy na 32 TB) + Maksimal'nyj razmer tablicy? 32 TB + Maksimal'nyj razmer zapisi? 1.6 TB + Maksimal'nyj razmer polya? 1 GB + Maksimal'noe kolichestvo zapisej v tablice? neogranicheno + Maksimal'noe kolichestvo kolonok v tablice? 250-1600 v zavisimosti ot tip +a + Maksimal'noe kolichestvo indeksov v tablice? neogranicheno Razumeetsya, ponyatie "neogranicheno" na samom dele ogranichivaetsya dostupnym diskovym prostranistvom i razmerami pamyati/svoppinga. Kogda @@ -810,26 +809,26 @@ pa priblizitel'no 6.4 MB iz kotoryh: 36 bajt: na kazhdyj zagolovok zapisi (priblizitel'no) + 24 bajta: odno pole s celochislennym tipom i odno tekstovoe pole - + 4 bajta: ukazatel' na stranice dlya vsej zapisi + + 4 bajta: ukazatel' na stranice dlya vsej zapisi ---------------------------------------- 64 bajt na zapis' Razmer stranicy dannyh v PostgreSQL sostavlyaet 8192 bajt (8 KB), tak chto: 8192 bajt na stranicu - ------------------- = 128 zapisej na stranicu BD (s okrugleniem) - 64 bajt na zapis' + --------------------- = 128 zapisej na stranicu BD (s okrugleniem) + 64 bajta na zapis' - 100000 strok dannyh - -------------------- = 782 stranicy v BD - 128 zapisej na stranicu + 100000 strok dannyh + ----------------------- = 782 stranicy v BD + 128 zapisej na stranicu -782 stranicy BD * 8192 bajt na stranicu = 6,406,144 bajt (6.4 MB) + 782 stranicy BD * 8192 bajt na stranicu = 6,406,144 bajt (6.4 MB) Indeksy ne trebuyut tak mnogo, no poskol'ku oni sozdayutsya dlya bol'shogo kolichestva dannyh, oni takzhe mogut byt' veliki. - Znacheniya NULL hranyatsya kak bitovae karty i po`etomu oni zanimayut + Znacheniya NULL hranyatsya kak bitovye karty i po`etomu oni zanimayut ochen' malo mesta. 4.7) Kak mne ubedit'sya, chto suschestvuyut nuzhnye mne tablicy, indeksy, @@ -879,7 +878,7 @@ pa ORDER BY col [ DESC ] LIMIT 1; - Esli vam kazhetsya, chto optimizator nekorretno vybiraet + Esli vam kazhetsya, chto optimizator nekorrektno vybiraet posledovatel'nyj perebor, ispol'zujte SET enable_seqscan TO 'off' i zapustite testy, chtoby uvidet', ne stalo-li skanirovanie indeksov bystree. @@ -918,7 +917,7 @@ pa Searching." Proceedings of the 1984 ACM SIGMOD Int'l Conf on Mgmt of Data, 45-57. - Vy mozhete najti `etot dokument v knige Stonebraker'a "Readings in + Vy mozhete najti `etot dokument v knige Stounbrejkera "Readings in Database Systems". Vstroennnye R-tree mogut upravlyat' poligonami i boksami. V teorii, @@ -1281,7 +1280,7 @@ CREATE TABLE test (x int, modtime timestamp DEFAULT CURRENT_TIMESTAMP ); Rasshireniya PostgreSQL 5.1) YA napisal funkciyu opredelyaemuyu pol'zovatelem. Kogda ya zapuskayu - ee v psql, pochemu ya poluchayu dump core? + ee v psql, pochemu ya poluchayu core dump? Problema mozhet zaklyuchat'sya v neskol'kih veschah. Popytajtes' sperva protestirovat' vashu funkciyu v otdel'noj samostoyatel'noj diff --git a/doc/src/FAQ/FAQ_russian.html b/doc/src/FAQ/FAQ_russian.html index 9f378d6ce09..d702ed7364c 100644 --- a/doc/src/FAQ/FAQ_russian.html +++ b/doc/src/FAQ/FAQ_russian.html @@ -12,7 +12,7 @@ <BODY bgcolor="#ffffff" text="#000000" link="#ff0000" vlink="#a00000" alink="#0000ff"> <H1>Ответы на часто задаваемые вопросы по PostgreSQL</H1> - <P>Дата последнего обновления: Суббота 7 февраля 22:16:21 EDT 2004</P> + <P>Дата последнего обновления: Воскресение 11 апреля 23:28:03 EDT 2004</P> <P>Английский вариант сопровождает: Брюс Момьян (Bruce Momjian) (<A href= "mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</A>)<BR> @@ -142,7 +142,7 @@ <H2 align="center">Расширения PostgreSQL</H2> <A href="#5.1">5.1</A>) Я написал функцию определяемую пользователем. - Когда я запускаю ее в <I>psql</I>, почему я получаю dump core?<BR> + Когда я запускаю ее в <I>psql</I>, почему я получаю core dump?<BR> <A href="#5.2">5.2</A>) Как я могу внести некоторые классные новые типы и функции в PostgreSQL?<BR> <A href="#5.3">5.3</A>) Как мне написать C функцию, возвращающую @@ -168,7 +168,7 @@ <P>Разработку PostgreSQL выполняет команда разработчиков, все участники которой подписаны на список рассылки разработчиков. В настоящее время, - их координатором является Марк Форнай (Marc G. Fournier) (<A href= + их координатором является Марк Фурнье (Marc G. Fournier) (<A href= "mailto:scrappy@PostgreSQL.org">scrappy@PostgreSQL.org</A>). (См. секцию <A href="#1.6">1.6</A> о том, как подключиться к разработке). Эта команда теперь отвечает за всю разработку PostgreSQL. Данный @@ -335,7 +335,7 @@ <H4><A name="1.7">1.7</A>) Какая последняя версия?</H4> - <P>Последний выпуск PostgreSQL - это версия 7.4.1</P> + <P>Последний выпуск PostgreSQL - это версия 7.4.2</P> <P>Мы планируем выпускать новые версии каждые 6-8 месяцев.</P> @@ -436,8 +436,8 @@ <DD>PostgreSQL имеет большинство возможностей представленных в больших коммерческих <SMALL>СУБД</SMALL>, такие как: транзакции, - подзапросы, триггеры, обзоры (views), внешний ключ ссылочной - целостности и разные блокировки. У нас есть некоторые возможности, + подзапросы, триггеры, представления, ссылочной + целостности вторичного ключа и разные блокировки. У нас есть некоторые возможности, которых нет у них: типы, определяемые пользователем, механизм наследования, правила и конкуретное многоверсионное управление для работы с содержимым блокировок.<BR> @@ -448,7 +448,7 @@ <DD>PostgreSQL имеет производительность схожую с другими коммерческими СУБД и с СУБД с открытым исходным кодом, в каких-то аспектах работая - быстрее чем они, в каких-то медленее. В сравнении с MySQL или линейными + быстрее чем они, в каких-то медленее. В сравнении с MySQL или обыденнее СУБД, мы быстрее, когда пользователей много, а также на комплексных запросах и чтении/записи загрузки запроса. MySQL быстрее для простых SELECT запросов, выполняемых небольшим количеством пользователей. @@ -509,7 +509,7 @@ <P>PostgreSQL имеет одноранговую инфраструктуру с того самого времени как мы начали разработку в 1996 году. Мы должны благодарить за - это Марка Фоная (Marc Fournier), который создал эту инфраструктуру и + это Марка Фурнье (Marc Fournier), который создал эту инфраструктуру и управляет ей на протяжении этих лет.</P> <P>Качественная инфраструктура очень важна для проектов с открытым @@ -860,7 +860,7 @@ команд.</P> <H4><A name="4.4">4.4</A>) Как удалить колонку из таблицы или - изменить ёё тип данных?</H4> + изменить её тип данных?</H4> <P><small>DROP COLUMN</small> функциональность была добавлена в выпуск 7.3 с оператором <small>ALTER TABLE DROP COLUMN</small>. В ранних версиях, @@ -890,13 +890,13 @@ <P>Существуют следующие ограничения:</P> <PRE> - Максимальный размер базы? неограничен (существуют базы на 32 TB) - Максимальный размер таблицы? 32 TB - Максимальный размер записи? 1.6 TB - Максимальный размер поля? 1 GB - Максимальное количество записей в таблице? неограничено - Максимальное количество колонок в таблице? 250-1600 в зависимости от типа - Максимальное количество индексов в таблице? неограничено + Максимальный размер базы? неограничен (существуют базы на 32 TB) + Максимальный размер таблицы? 32 TB + Максимальный размер записи? 1.6 TB + Максимальный размер поля? 1 GB + Максимальное количество записей в таблице? неограничено + Максимальное количество колонок в таблице? 250-1600 в зависимости от типа + Максимальное количество индексов в таблице? неограничено </PRE> Разумеется, понятие "неограничено" на самом деле ограничивается @@ -927,27 +927,27 @@ <PRE> 36 байт: на каждый заголовок записи (приблизительно) + 24 байта: одно поле с целочисленным типом и одно текстовое поле - + 4 байта: указатель на странице для всей записи + + 4 байта: указатель на странице для всей записи ---------------------------------------- 64 байт на запись Размер страницы данных в PostgreSQL составляет 8192 байт (8 KB), так что: 8192 байт на страницу - ------------------- = 128 записей на страницу БД (с округлением) - 64 байт на запись + --------------------- = 128 записей на страницу БД (с округлением) + 64 байта на запись - 100000 строк данных - -------------------- = 782 страницы в БД - 128 записей на страницу + 100000 строк данных + ----------------------- = 782 страницы в БД + 128 записей на страницу -782 страницы БД * 8192 байт на страницу = 6,406,144 байт (6.4 MB) + 782 страницы БД * 8192 байт на страницу = 6,406,144 байт (6.4 MB) </PRE> <P>Индексы не требуют так много, но поскольку они создаются для большого количества данных, они также могут быть велики.</P> - <P>Значения <small>NULL</small> хранятся как битовае карты и поэтому они + <P>Значения <small>NULL</small> хранятся как битовые карты и поэтому они занимают очень мало места. </P> @@ -999,7 +999,7 @@ LIMIT 1; </pre> - <P>Если вам кажется, что оптимизатор некорретно выбирает последовательный + <P>Если вам кажется, что оптимизатор некорректно выбирает последовательный перебор, используйте <CODE>SET enable_seqscan TO 'off'</CODE> и запустите тесты, чтобы увидеть, не стало-ли сканирование индексов быстрее. </P> @@ -1043,7 +1043,7 @@ Searching." Proceedings of the 1984 ACM SIGMOD Int'l Conf on Mgmt of Data, 45-57.</P> - <P>Вы можете найти этот документ в книге Stonebraker'а "Readings in + <P>Вы можете найти этот документ в книге Стоунбрейкера "Readings in Database Systems".</P> <P>Встроеннные R-tree могут управлять полигонами и боксами. В теории, @@ -1467,7 +1467,7 @@ BYTEA bytea массив байт переменной длины (можно использовать <H2 align="center">Расширения PostgreSQL</H2> <H4><A name="5.1">5.1</A>) Я написал функцию определяемую пользователем. - Когда я запускаю ее в <I>psql</I>, почему я получаю dump core?</H4> + Когда я запускаю ее в <I>psql</I>, почему я получаю core dump?</H4> <P>Проблема может заключаться в нескольких вещах. Попытайтесь сперва протестировать вашу функцию в отдельной самостоятельной программе.</P> @@ -1496,4 +1496,3 @@ BYTEA bytea массив байт переменной длины (можно использовать автоматически отслеживать зависимости.</P> </BODY> </HTML> - |