Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit d5f6cfc

Browse files
committed
Update Russian FAQ, both branches.
Viktor Vislobokov
1 parent 3c0ddc5 commit d5f6cfc

File tree

2 files changed

+40
-35
lines changed

2 files changed

+40
-35
lines changed

doc/FAQ_russian

+21-17
Original file line numberDiff line numberDiff line change
@@ -1,12 +1,12 @@
11

22
Otvety na chasto zadavaemye voprosy po PostgreSQL
33

4-
Data poslednego obnovleniya: Voskresen'e 5 Oktyabrya 10:25:21 EDT 2003
4+
Data poslednego obnovleniya: Sreda 19 noyabrya 11:50:04 EDT 2003
55

66
Anglijskij variant soprovozhdaet: Bryus Mom'yan (Bruce Momjian)
77
(pgman@candle.pha.pa.us)
88

9-
Perevel na russkij: Viktor Vislobokov (victor_v@permonline.ru)
9+
Perevel na russkij: Viktor Vislobokov (corochoone@perm.ru)
1010

1111
Samuyu svezhuyu anglijskuyu versiyu dokumenta mozhno najti na
1212
http://www.PostgreSQL.org/docs/faqs/FAQ.html.
@@ -273,16 +273,17 @@
273273

274274
http://www.PostgreSQL.org
275275

276-
Esche suschestvuet IRC kanal na EFNet i OpenProjects, s nazvaniem
276+
Esche suschestvuet IRC kanal na EFNet i Freenode, s nazvaniem
277277
#PostgreSQL. YA ispol'zuyu dlya podklyucheniya k `etomu kanalu komandu
278-
Unix irc -c '#PostgreSQL' "$USER" irc.phoenix.net.
278+
Unix irc -c '#PostgreSQL' "$USER" irc.phoenix.net. ili irc -c
279+
'#PostgreSQL' "$USER" irc.freenode.net.
279280

280281
Spisok kommercheskoj podderzhki kompanij dostupen na
281282
http://techdocs.postgresql.org/companies.php.
282283

283284
1.7) Kakaya poslednyaya versiya?
284285

285-
Poslednij vypusk PostgreSQL - `eto versiya 7.3.4.
286+
Poslednij vypusk PostgreSQL - `eto versiya 7.4.
286287

287288
My planiruem vypuskat' novye versii kazhdye 6-8 mesyacev.
288289

@@ -485,7 +486,7 @@
485486
2.3) Est' li u PostgreSQL graficheskij interfejs pol'zovatelya?
486487

487488
Da, suschestvuet neskol'ko graficheskih interfejsov dlya PostgreSQL.
488-
`Eto PgAccess (http://www.pgaccess.org, PgAdmin II
489+
`Eto PgAccess (http://www.pgaccess.org, PgAdmin III
489490
(http://www.pgadmin.org, Win32-only), RHDB Admin (
490491
http://sources.redhat.com/rhdb/) i Rekall (
491492
http://www.thekompany.com/products/rekall/, kommercheskij). Takzhe
@@ -770,7 +771,7 @@ dalit'
770771

771772
Suschestvuyut sleduyuschie ogranicheniya:
772773
Maksimal'nyj razmer bazy? neogranichen (suschestvuyut bazy na
773-
4 TB)
774+
32 TB)
774775
Maksimal'nyj razmer tablicy? 32 TB
775776
Maksimal'nyj razmer zapisi? 1.6 TB
776777
Maksimal'nyj razmer polya? 1 GB
@@ -990,7 +991,7 @@ t' null-bajt bez opaski)
990991
4.15.1) Kak mne sozdat' pole serial/s-avto-uvelicheniem?
991992

992993
PostgreSQL podderzhivaet tip dannyh SERIAL. On avtomaticheski sozdaet
993-
posledovatel'nost' i indeks dlya kolonki. Naprimer:
994+
posledovatel'nost'. Naprimer:
994995
CREATE TABLE person (
995996
id SERIAL,
996997
name TEXT
@@ -1002,7 +1003,6 @@ t' null-bajt bez opaski)
10021003
id INT4 NOT NULL DEFAULT nextval('person_id_seq'),
10031004
name TEXT
10041005
);
1005-
CREATE UNIQUE INDEX person_id_key ON person ( id );
10061006

10071007
Smotrite podrobnosti o posledovatel'nostyah na stranice rukovodstva
10081008
posvyaschennoj create_sequence. Vy takzhe mozhete ispol'zovat' kazhdoe
@@ -1160,12 +1160,12 @@ CREATE TABLE test (x int, modtime timestamp DEFAULT CURRENT_TIMESTAMP );
11601160

11611161
4.22) Pochemu moi podzaprosy, ispol'zuyuschie IN tak medlenno rabotaeyut?
11621162

1163-
V nastoyaschij moment, my svyazyvaem pozaprosy dlya vneshnih zaprosov
1164-
cherez posledovatel'nyj perebor rezul'tata podzaprosa dlya kazhdoj
1165-
zapisi vneshnego zaprosa. Esli podzapros vozvraschaet tol'ko neskol'ko
1166-
zapisej i vneshnij zapros vozvraschaet mnogo zapisej, IN rabotaet
1167-
naibolee bystro. CHtoby uvelichit' skorost' v drugih zaprosah,
1168-
zamenite IN na EXISTS:
1163+
V versiyah do 7.4, podzaprosy svyazyvalis' s roditel'skimi zaprosami
1164+
cherez posledovatel'nyj perebor rezul'tatov pozaprosa dlya kazhdoj
1165+
zapisi roditel'skogo zaprosa. Esli podzapros vozvraschaet tol'ko
1166+
neskol'ko zapisej, a roditel'skij zapros vozvraschaet mnogo zapisej,
1167+
IN rabotaet naibolee bystro. CHtoby uvelichit' skorost' v drugih
1168+
zaprosah, zamenite IN na EXISTS:
11691169
SELECT *
11701170
FROM tab
11711171
WHERE col IN (SELECT subcol FROM subtab);
@@ -1176,8 +1176,12 @@ CREATE TABLE test (x int, modtime timestamp DEFAULT CURRENT_TIMESTAMP );
11761176
WHERE EXISTS (SELECT subcol FROM subtab WHERE subcol = col);
11771177

11781178
CHtoby takaya konstrukciya rabotala bystro, kolonka subcol dolzhna
1179-
byt' proindeksirovana. `Eta problema proizvoditel'nosti budet
1180-
ustranena v versii 7.4.
1179+
byt' proindeksirovana.
1180+
1181+
V versii 7.4 i vyshe, IN fakticheski ispol'zuet takoj zhe mehanizm
1182+
svyazyvaniya kak i obychnye zaprosy, po`etomu predpochtitel'nym
1183+
yavlyaetsya ispol'zovanie EXISTS
1184+
.
11811185

11821186
4.23) Kak mne vypolnit' vneshnee svyazyvanie?
11831187

doc/src/FAQ/FAQ_russian.html

+19-18
Original file line numberDiff line numberDiff line change
@@ -9,17 +9,16 @@
99
<TITLE>PostgreSQL FAQ</TITLE>
1010
</HEAD>
1111

12-
<BODY bgcolor="#ffffff" text="#000000" link="#ff0000" vlink="#a00000"
13-
alink="#0000ff">
12+
<BODY bgcolor="#ffffff" text="#000000" link="#ff0000" vlink="#a00000" alink="#0000ff">
1413
<H1>Ответы на часто задаваемые вопросы по PostgreSQL</H1>
1514

16-
<P>Дата последнего обновления: Воскресенье 5 Октября 10:25:21 EDT 2003</P>
15+
<P>Дата последнего обновления: Среда 19 ноября 11:50:04 EDT 2003</P>
1716

1817
<P>Английский вариант сопровождает: Брюс Момьян (Bruce Momjian) (<A href=
1918
"mailto:pgman@candle.pha.pa.us">pgman@candle.pha.pa.us</A>)<BR>
2019
</P>
2120
<P>Перевел на русский: Виктор Вислобоков (<A href=
22-
"mailto:pgman@candle.pha.pa.us">victor_v@permonline.ru</A>)<BR>
21+
"mailto:pgman@candle.pha.pa.us">corochoone@perm.ru</A>)<BR>
2322
</P>
2423

2524
<P>Самую свежую английскую версию документа можно найти на
@@ -321,16 +320,17 @@
321320
<A href="http://www.PostgreSQL.org">http://www.PostgreSQL.org</A>
322321
</BLOCKQUOTE>
323322

324-
<P>Еще существует IRC канал на EFNet и OpenProjects, с названием
323+
<P>Еще существует IRC канал на EFNet и Freenode, с названием
325324
<I>#PostgreSQL</I>. Я использую для подключения к этому каналу команду Unix
326-
<CODE>irc -c '#PostgreSQL' "$USER" irc.phoenix.net.</CODE></P>
325+
<CODE>irc -c '#PostgreSQL' "$USER" irc.phoenix.net.</CODE> или
326+
<CODE>irc -c '#PostgreSQL' "$USER" irc.freenode.net.</CODE></P>
327327

328328
<P>Список коммерческой поддержки компаний доступен на
329329
<A href="http://techdocs.postgresql.org/companies.php">http://techdocs.postgresql.org/companies.php</A>.</P>
330330

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

333-
<P>Последний выпуск PostgreSQL - это версия 7.3.4.</P>
333+
<P>Последний выпуск PostgreSQL - это версия 7.4.</P>
334334

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

@@ -566,7 +566,7 @@
566566

567567
<P>Да, существует несколько графических интерфейсов для PostgreSQL.
568568
Это PgAccess (<A href="http://www.pgaccess.org/">http://www.pgaccess.org</A>,
569-
PgAdmin II (<A href="http://www.pgadmin.org/">http://www.pgadmin.org</A>,
569+
PgAdmin III (<A href="http://www.pgadmin.org/">http://www.pgadmin.org</A>,
570570
Win32-only), RHDB Admin (<A href="http://sources.redhat.com/rhdb/">
571571
http://sources.redhat.com/rhdb/</A>) и Rekall
572572
(<A href="http://www.thekompany.com/products/rekall/">
@@ -885,7 +885,7 @@
885885

886886
<P>Существуют следующие ограничения:</P>
887887
<PRE>
888-
Максимальный размер базы? неограничен (существуют базы на 4 TB)
888+
Максимальный размер базы? неограничен (существуют базы на 32 TB)
889889
Максимальный размер таблицы? 32 TB
890890
Максимальный размер записи? 1.6 TB
891891
Максимальный размер поля? 1 GB
@@ -1122,8 +1122,7 @@
11221122
serial/с-авто-увеличением?</H4>
11231123

11241124
<P>PostgreSQL поддерживает тип данных <SMALL>SERIAL</SMALL>. Он
1125-
автоматически создает последовательность и индекс для колонки.
1126-
Например:</P>
1125+
автоматически создает последовательность. Например:</P>
11271126
<PRE>
11281127
CREATE TABLE person (
11291128
id SERIAL,
@@ -1138,7 +1137,6 @@
11381137
id INT4 NOT NULL DEFAULT nextval('person_id_seq'),
11391138
name TEXT
11401139
);
1141-
CREATE UNIQUE INDEX person_id_key ON person ( id );
11421140
</PRE>
11431141

11441142
Смотрите подробности о последовательностях на странице руководства
@@ -1334,10 +1332,10 @@
13341332
<H4><A name="4.22">4.22</A>) Почему мои подзапросы, использующие
13351333
<CODE><SMALL>IN</SMALL></CODE> так медленно работаеют?</H4>
13361334

1337-
<P>В настоящий момент, мы связываем позапросы для внешних запросов
1338-
через последовательный перебор результата подзапроса для каждой
1339-
записи внешнего запроса. Если подзапрос возвращает только несколько
1340-
записей и внешний запрос возвращает много записей,
1335+
<P>В версиях до 7.4, подзапросы связывались с родительскими запросами
1336+
через последовательный перебор результатов позапроса для каждой
1337+
записи родительского запроса. Если подзапрос возвращает только несколько
1338+
записей, а родительский запрос возвращает много записей,
13411339
<CODE><SMALL>IN</SMALL></CODE> работает наиболее быстро. Чтобы
13421340
увеличить скорость в других запросах, замените <CODE>IN</CODE> на
13431341
<CODE>EXISTS</CODE>:</P>
@@ -1355,8 +1353,11 @@
13551353
</PRE>
13561354

13571355
Чтобы такая конструкция работала быстро, колонка <CODE>subcol</CODE>
1358-
должна быть проиндексирована. Эта проблема производительности будет
1359-
устранена в версии 7.4.
1356+
должна быть проиндексирована.
1357+
1358+
<P>В версии 7.4 и выше, <CODE>IN</CODE> фактически использует такой же
1359+
механизм связывания как и обычные запросы, поэтому предпочтительным
1360+
является использование <CODE>EXISTS</CODE></P>.
13601361

13611362
<H4><A name="4.23">4.23</A>) Как мне выполнить внешнее связывание?</H4>
13621363

0 commit comments

Comments
 (0)