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

Lines changed: 21 additions & 17 deletions
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

Lines changed: 19 additions & 18 deletions
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)
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy