Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Commit7b3189c

Browse files
committed
> > This update fixes a few small typos in names,
> > pronouns and formatting in the Russian FAQ.Serguei Mokhov
1 parent3c4ab3f commit7b3189c

File tree

2 files changed

+59
-61
lines changed

2 files changed

+59
-61
lines changed

‎doc/FAQ_russian

Lines changed: 32 additions & 33 deletions
Original file line numberDiff line numberDiff line change
@@ -1,7 +1,7 @@
11

22
Otvety na chasto zadavaemye voprosy po PostgreSQL
33

4-
Data poslednego obnovleniya:Subbota 7 fevralya 22:16:21 EDT 2004
4+
Data poslednego obnovleniya:Voskresenie 11 aprelya 23:28:03 EDT 2004
55

66
Anglijskij variant soprovozhdaet: Bryus Mom'yan (Bruce Momjian)
77
(pgman@candle.pha.pa.us)
@@ -114,7 +114,7 @@
114114
Rasshireniya PostgreSQL
115115

116116
5.1) YA napisal funkciyu opredelyaemuyu pol'zovatelem. Kogda ya
117-
zapuskayu ee v psql, pochemu ya poluchayudumpcore?
117+
zapuskayu ee v psql, pochemu ya poluchayu core dump?
118118
5.2) Kak ya mogu vnesti nekotorye klassnye novye tipy i funkcii v
119119
PostgreSQL?
120120
5.3) Kak mne napisat' C funkciyu, vozvraschayuschuyu zapis'?
@@ -138,7 +138,7 @@
138138

139139
Razrabotku PostgreSQL vypolnyaet komanda razrabotchikov, vse
140140
uchastniki kotoroj podpisany na spisok rassylki razrabotchikov. V
141-
nastoyaschee vremya, ih koordinatorom yavlyaetsya MarkFornaj (Marc G.
141+
nastoyaschee vremya, ih koordinatorom yavlyaetsya MarkFurn'e (Marc G.
142142
Fournier) (scrappy@PostgreSQL.org). (Sm. sekciyu 1.6 o tom, kak
143143
podklyuchit'sya k razrabotke). `Eta komanda teper' otvechaet za vsyu
144144
razrabotku PostgreSQL. Dannyj proekt yavlyaetsya obschestvennym i ne
@@ -286,7 +286,7 @@
286286

287287
1.7) Kakaya poslednyaya versiya?
288288

289-
Poslednij vypusk PostgreSQL - `eto versiya 7.4.1
289+
Poslednij vypusk PostgreSQL - `eto versiya 7.4.2
290290

291291
My planiruem vypuskat' novye versii kazhdye 6-8 mesyacev.
292292

@@ -370,18 +370,17 @@
370370
Vozmozhnosti
371371
PostgreSQL imeet bol'shinstvo vozmozhnostej predstavlennyh v
372372
bol'shih kommercheskih SUBD, takie kak: tranzakcii, podzaprosy,
373-
triggery, obzory (views), vneshnij klyuch ssylochnoj
374-
celostnosti i raznye blokirovki. U nas est' nekotorye
375-
vozmozhnosti, kotoryh net u nih: tipy, opredelyaemye
376-
pol'zovatelem, mehanizm nasledovaniya, pravila i konkuretnoe
377-
mnogoversionnoe upravlenie dlya raboty s soderzhimym
378-
blokirovok.
373+
triggery, predstavleniya, ssylochnoj celostnosti vtorichnogo
374+
klyucha i raznye blokirovki. U nas est' nekotorye vozmozhnosti,
375+
kotoryh net u nih: tipy, opredelyaemye pol'zovatelem, mehanizm
376+
nasledovaniya, pravila i konkuretnoe mnogoversionnoe upravlenie
377+
dlya raboty s soderzhimym blokirovok.
379378

380379
Proizvoditel'nost'
381380
PostgreSQL imeet proizvoditel'nost' shozhuyu s drugimi
382381
kommercheskimi SUBD i s SUBD s otkrytym ishodnym kodom, v
383382
kakih-to aspektah rabotaya bystree chem oni, v kakih-to
384-
medlenee. V sravnenii s MySQL ililinejnymi SUBD, my bystree,
383+
medlenee. V sravnenii s MySQL iliobydennee SUBD, my bystree,
385384
kogda pol'zovatelej mnogo, a takzhe na kompleksnyh zaprosah i
386385
chtenii/zapisi zagruzki zaprosa. MySQL bystree dlya prostyh
387386
SELECT zaprosov, vypolnyaemyh nebol'shim kolichestvom
@@ -432,7 +431,7 @@
432431

433432
PostgreSQL imeet odnorangovuyu infrastrukturu s togo samogo vremeni
434433
kak my nachali razrabotku v 1996 godu. My dolzhny blagodarit' za `eto
435-
MarkaFonaya (Marc Fournier), kotoryj sozdal `etu infrastrukturu i
434+
MarkaFurn'e (Marc Fournier), kotoryj sozdal `etu infrastrukturu i
436435
upravlyaet ej na protyazhenii `etih let.
437436

438437
Kachestvennaya infrastruktura ochen' vazhna dlya proektov s otkrytym
@@ -749,7 +748,7 @@
749748
chtoby `eta programma vydavala zaprosy, kotorye ona ispol'zuet dlya
750749
vypolneniya zadannyh vami komand.
751750

752-
4.4) Kak udalit' kolonku iz tablicy ili izmenit'ioio tip dannyh?
751+
4.4) Kak udalit' kolonku iz tablicy ili izmenit'eio tip dannyh?
753752

754753
DROP COLUMN funkcional'nost' byla dobavlena v vypusk 7.3 s operatorom
755754
ALTER TABLE DROP COLUMN. V rannih versiyah, mozhno sdelat' tak:
@@ -773,15 +772,15 @@ dalit'
773772
4.5) Kakovy maksimal'nye razmery dlya zapisej, tablic i bazy dannyh?
774773

775774
Suschestvuyut sleduyuschie ogranicheniya:
776-
Maksimal'nyj razmer bazy? neogranichen (suschestvuyutbazy na
777-
32 TB)
778-
Maksimal'nyj razmer tablicy? 32 TB
779-
Maksimal'nyj razmer zapisi? 1.6 TB
780-
Maksimal'nyj razmer polya? 1 GB
781-
Maksimal'noe kolichestvo zapisej v tablice?neogranicheno
782-
Maksimal'noe kolichestvo kolonok v tablice?250-1600 v zavisimosti otti
783-
pa
784-
Maksimal'noe kolichestvo indeksov v tablice?neogranicheno
775+
Maksimal'nyj razmer bazy?neogranichen (suschestvuyutba
776+
zy na32 TB)
777+
Maksimal'nyj razmer tablicy?32 TB
778+
Maksimal'nyj razmer zapisi?1.6 TB
779+
Maksimal'nyj razmer polya?1 GB
780+
Maksimal'noe kolichestvo zapisej v tablice? neogranicheno
781+
Maksimal'noe kolichestvo kolonok v tablice? 250-1600 v zavisimosti ottip
782+
a
783+
Maksimal'noe kolichestvo indeksov v tablice? neogranicheno
785784

786785
Razumeetsya, ponyatie "neogranicheno" na samom dele ogranichivaetsya
787786
dostupnym diskovym prostranistvom i razmerami pamyati/svoppinga. Kogda
@@ -810,26 +809,26 @@ pa
810809
priblizitel'no 6.4 MB iz kotoryh:
811810
36 bajt: na kazhdyj zagolovok zapisi (priblizitel'no)
812811
+ 24 bajta: odno pole s celochislennym tipom i odno tekstovoe pole
813-
+ 4 bajta: ukazatel' na stranice dlya vsej zapisi
812+
+ 4 bajta: ukazatel' na stranice dlya vsej zapisi
814813
----------------------------------------
815814
64 bajt na zapis'
816815

817816
Razmer stranicy dannyh v PostgreSQL sostavlyaet 8192 bajt (8 KB), tak chto:
818817

819818
8192 bajt na stranicu
820-
------------------- = 128 zapisej na stranicu BD (s okrugleniem)
821-
64bajt na zapis'
819+
--------------------- = 128 zapisej na stranicu BD (s okrugleniem)
820+
64bajta na zapis'
822821

823-
100000 strok dannyh
824-
-------------------- = 782 stranicy v BD
825-
128 zapisej na stranicu
822+
100000 strok dannyh
823+
----------------------- = 782 stranicy v BD
824+
128 zapisej na stranicu
826825

827-
782 stranicy BD * 8192 bajt na stranicu = 6,406,144 bajt (6.4 MB)
826+
782 stranicy BD * 8192 bajt na stranicu= 6,406,144 bajt (6.4 MB)
828827

829828
Indeksy ne trebuyut tak mnogo, no poskol'ku oni sozdayutsya dlya
830829
bol'shogo kolichestva dannyh, oni takzhe mogut byt' veliki.
831830

832-
Znacheniya NULL hranyatsya kakbitovae karty i po`etomu oni zanimayut
831+
Znacheniya NULL hranyatsya kakbitovye karty i po`etomu oni zanimayut
833832
ochen' malo mesta.
834833

835834
4.7) Kak mne ubedit'sya, chto suschestvuyut nuzhnye mne tablicy, indeksy,
@@ -879,7 +878,7 @@ pa
879878
ORDER BY col [ DESC ]
880879
LIMIT 1;
881880

882-
Esli vam kazhetsya, chto optimizatornekorretno vybiraet
881+
Esli vam kazhetsya, chto optimizatornekorrektno vybiraet
883882
posledovatel'nyj perebor, ispol'zujte SET enable_seqscan TO 'off' i
884883
zapustite testy, chtoby uvidet', ne stalo-li skanirovanie indeksov
885884
bystree.
@@ -918,7 +917,7 @@ pa
918917
Searching." Proceedings of the 1984 ACM SIGMOD Int'l Conf on Mgmt of
919918
Data, 45-57.
920919

921-
Vy mozhete najti `etot dokument v knigeStonebraker'a "Readings in
920+
Vy mozhete najti `etot dokument v knigeStounbrejkera "Readings in
922921
Database Systems".
923922

924923
Vstroennnye R-tree mogut upravlyat' poligonami i boksami. V teorii,
@@ -1281,7 +1280,7 @@ CREATE TABLE test (x int, modtime timestamp DEFAULT CURRENT_TIMESTAMP );
12811280
Rasshireniya PostgreSQL
12821281

12831282
5.1) YA napisal funkciyu opredelyaemuyu pol'zovatelem. Kogda ya zapuskayu
1284-
ee v psql, pochemu ya poluchayudumpcore?
1283+
ee v psql, pochemu ya poluchayu core dump?
12851284

12861285
Problema mozhet zaklyuchat'sya v neskol'kih veschah. Popytajtes'
12871286
sperva protestirovat' vashu funkciyu v otdel'noj samostoyatel'noj

‎doc/src/FAQ/FAQ_russian.html

Lines changed: 27 additions & 28 deletions
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,7 @@
1212
<BODYbgcolor="#ffffff"text="#000000"link="#ff0000"vlink="#a00000"alink="#0000ff">
1313
<H1>Ответы на часто задаваемые вопросы по PostgreSQL</H1>
1414

15-
<P>Дата последнего обновления:Суббота 7 февраля 22:16:21 EDT 2004</P>
15+
<P>Дата последнего обновления:Воскресение 11 апреля 23:28:03 EDT 2004</P>
1616

1717
<P>Английский вариант сопровождает: Брюс Момьян (Bruce Momjian) (<Ahref=
1818
"mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</A>)<BR>
@@ -142,7 +142,7 @@
142142

143143
<H2align="center">Расширения PostgreSQL</H2>
144144
<Ahref="#5.1">5.1</A>) Я написал функцию определяемую пользователем.
145-
Когда я запускаю ее в<I>psql</I>, почему я получаюdumpcore?<BR>
145+
Когда я запускаю ее в<I>psql</I>, почему я получаю core dump?<BR>
146146
<Ahref="#5.2">5.2</A>) Как я могу внести некоторые классные новые
147147
типы и функции в PostgreSQL?<BR>
148148
<Ahref="#5.3">5.3</A>) Как мне написать C функцию, возвращающую
@@ -168,7 +168,7 @@
168168

169169
<P>Разработку PostgreSQL выполняет команда разработчиков, все участники
170170
которой подписаны на список рассылки разработчиков. В настоящее время,
171-
их координатором является МаркФорнай (Marc G. Fournier) (<Ahref=
171+
их координатором является МаркФурнье (Marc G. Fournier) (<Ahref=
172172
"mailto:scrappy@PostgreSQL.org">scrappy@PostgreSQL.org</A>). (См.
173173
секцию<Ahref="#1.6">1.6</A> о том, как подключиться к разработке).
174174
Эта команда теперь отвечает за всю разработку PostgreSQL. Данный
@@ -335,7 +335,7 @@
335335

336336
<H4><Aname="1.7">1.7</A>) Какая последняя версия?</H4>
337337

338-
<P>Последний выпуск PostgreSQL - это версия 7.4.1</P>
338+
<P>Последний выпуск PostgreSQL - это версия 7.4.2</P>
339339

340340
<P>Мы планируем выпускать новые версии каждые 6-8 месяцев.</P>
341341

@@ -436,8 +436,8 @@
436436

437437
<DD>PostgreSQL имеет большинство возможностей представленных
438438
в больших коммерческих<SMALL>СУБД</SMALL>, такие как: транзакции,
439-
подзапросы, триггеры,обзоры (views), внешний ключ ссылочной
440-
целостности и разные блокировки. У нас есть некоторые возможности,
439+
подзапросы, триггеры,представления, ссылочной
440+
целостностивторичного ключаи разные блокировки. У нас есть некоторые возможности,
441441
которых нет у них: типы, определяемые пользователем, механизм
442442
наследования, правила и конкуретное многоверсионное управление
443443
для работы с содержимым блокировок.<BR>
@@ -448,7 +448,7 @@
448448

449449
<DD>PostgreSQL имеет производительность схожую с другими коммерческими
450450
СУБД и с СУБД с открытым исходным кодом, в каких-то аспектах работая
451-
быстрее чем они, в каких-то медленее. В сравнении с MySQL илилинейными
451+
быстрее чем они, в каких-то медленее. В сравнении с MySQL илиобыденнее
452452
СУБД, мы быстрее, когда пользователей много, а также на комплексных
453453
запросах и чтении/записи загрузки запроса. MySQL быстрее для простых
454454
SELECT запросов, выполняемых небольшим количеством пользователей.
@@ -509,7 +509,7 @@
509509

510510
<P>PostgreSQL имеет одноранговую инфраструктуру с того самого времени
511511
как мы начали разработку в 1996 году. Мы должны благодарить за
512-
это МаркаФоная (Marc Fournier), который создал эту инфраструктуру и
512+
это МаркаФурнье (Marc Fournier), который создал эту инфраструктуру и
513513
управляет ей на протяжении этих лет.</P>
514514

515515
<P>Качественная инфраструктура очень важна для проектов с открытым
@@ -860,7 +860,7 @@
860860
команд.</P>
861861

862862
<H4><Aname="4.4">4.4</A>) Как удалить колонку из таблицы или
863-
изменитьёё тип данных?</H4>
863+
изменитьеё тип данных?</H4>
864864

865865
<P><small>DROP COLUMN</small> функциональность была добавлена в выпуск
866866
7.3 с оператором<small>ALTER TABLE DROP COLUMN</small>. В ранних версиях,
@@ -890,13 +890,13 @@
890890

891891
<P>Существуют следующие ограничения:</P>
892892
<PRE>
893-
Максимальный размер базы? неограничен (существуют базы на 32 TB)
894-
Максимальный размер таблицы? 32 TB
895-
Максимальный размер записи? 1.6 TB
896-
Максимальный размер поля? 1 GB
897-
Максимальное количество записей в таблице?неограничено
898-
Максимальное количество колонок в таблице?250-1600 в зависимости от типа
899-
Максимальное количество индексов в таблице?неограничено
893+
Максимальный размер базы?неограничен (существуют базы на 32 TB)
894+
Максимальный размер таблицы?32 TB
895+
Максимальный размер записи?1.6 TB
896+
Максимальный размер поля?1 GB
897+
Максимальное количество записей в таблице? неограничено
898+
Максимальное количество колонок в таблице? 250-1600 в зависимости от типа
899+
Максимальное количество индексов в таблице? неограничено
900900
</PRE>
901901

902902
Разумеется, понятие "неограничено" на самом деле ограничивается
@@ -927,27 +927,27 @@
927927
<PRE>
928928
36 байт: на каждый заголовок записи (приблизительно)
929929
+ 24 байта: одно поле с целочисленным типом и одно текстовое поле
930-
+ 4 байта: указатель на странице для всей записи
930+
+ 4 байта: указатель на странице для всей записи
931931
----------------------------------------
932932
64 байт на запись
933933

934934
Размер страницы данных в PostgreSQL составляет 8192 байт (8 KB), так что:
935935

936936
8192 байт на страницу
937-
------------------- = 128 записей на страницу БД (с округлением)
938-
64байт на запись
937+
--------------------- = 128 записей на страницу БД (с округлением)
938+
64байта на запись
939939

940-
100000 строк данных
941-
-------------------- = 782 страницы в БД
942-
128 записей на страницу
940+
100000 строк данных
941+
----------------------- = 782 страницы в БД
942+
128 записей на страницу
943943

944-
782 страницы БД * 8192 байт на страницу = 6,406,144 байт (6.4 MB)
944+
782 страницы БД * 8192 байт на страницу= 6,406,144 байт (6.4 MB)
945945
</PRE>
946946

947947
<P>Индексы не требуют так много, но поскольку они создаются для
948948
большого количества данных, они также могут быть велики.</P>
949949

950-
<P>Значения<small>NULL</small> хранятся какбитовае карты и поэтому они
950+
<P>Значения<small>NULL</small> хранятся какбитовые карты и поэтому они
951951
занимают очень мало места.
952952
</P>
953953

@@ -999,7 +999,7 @@
999999
LIMIT 1;
10001000
</pre>
10011001

1002-
<P>Если вам кажется, что оптимизаторнекорретно выбирает последовательный
1002+
<P>Если вам кажется, что оптимизаторнекорректно выбирает последовательный
10031003
перебор, используйте<CODE>SET enable_seqscan TO 'off'</CODE> и
10041004
запустите тесты, чтобы увидеть, не стало-ли сканирование индексов быстрее.
10051005
</P>
@@ -1043,7 +1043,7 @@
10431043
Searching." Proceedings of the 1984 ACM SIGMOD Int'l Conf on Mgmt
10441044
of Data, 45-57.</P>
10451045

1046-
<P>Вы можете найти этот документ в книгеStonebraker'а "Readings in
1046+
<P>Вы можете найти этот документ в книгеСтоунбрейкера "Readings in
10471047
Database Systems".</P>
10481048

10491049
<P>Встроеннные R-tree могут управлять полигонами и боксами. В теории,
@@ -1467,7 +1467,7 @@
14671467
<H2align="center">Расширения PostgreSQL</H2>
14681468

14691469
<H4><Aname="5.1">5.1</A>) Я написал функцию определяемую пользователем.
1470-
Когда я запускаю ее в<I>psql</I>, почему я получаюdumpcore?</H4>
1470+
Когда я запускаю ее в<I>psql</I>, почему я получаю core dump?</H4>
14711471

14721472
<P>Проблема может заключаться в нескольких вещах. Попытайтесь сперва
14731473
протестировать вашу функцию в отдельной самостоятельной программе.</P>
@@ -1496,4 +1496,3 @@
14961496
автоматически отслеживать зависимости.</P>
14971497
</BODY>
14981498
</HTML>
1499-

0 commit comments

Comments
 (0)
[8]ページ先頭
©2009-2025 Movatter.jp