postgresql/doc/FAQ_russian

1272 lines
58 KiB
Plaintext
Raw Normal View History

Otvety na chasto zadavaemye voprosy po PostgreSQL
2002-04-12 17:17:10 +08:00
Data poslednego obnovleniya: Ponedel'nik 22 Aprelya 14:02:41 EDT 2003
2002-04-12 17:17:10 +08:00
Anglijskij variant soprovozhdaet: Bryus Mom'yan (Bruce Momjian)
2002-04-12 17:17:10 +08:00
(pgman@candle.pha.pa.us)
Perevel na russkij: Viktor Vislobokov (victor_v@permonline.ru)
2002-04-12 17:17:10 +08:00
Samuyu svezhuyu anglijskuyu versiyu dokumenta mozhno najti na
http://www.PostgreSQL.org/docs/faqs/FAQ.html.
2002-04-12 17:17:10 +08:00
Otvety na voprosy specifichnye dlya konkretnyh platform mozhno najti
na http://www.PostgreSQL.org/docs/index.html.
2002-04-12 17:17:10 +08:00
_________________________________________________________________
Obschie voprosy
2002-04-12 17:17:10 +08:00
1.1) CHto takoe PostgreSQL? Kak proiznositsya `eto nazvanie?
1.2) Kakovy avtorskie prava na PostgreSQL?
1.3) Na kakih Unix platformah rabotaet PostgreSQL?
1.4) Suschestvuyut li versii portirovannye ne na Unix sistemy?
1.5) Gde mozhno vzyat' PostgreSQL?
1.6) Gde poluchit' podderzhku?
1.7) Kakaya poslednyaya versiya?
1.8) Kakaya dokumentaciya imeetsya v nalichii?
1.9) Kak najti informaciyu ob izvestnyh oshibkah ili otsutstvuyuschih
vozmozhnostyah?
1.10) Kak nauchit'sya SQL?
1.11) Reshena li v PostgreSQL problema 2000-go goda (Y2K)?
1.12) Kak prisoedinitsya k komande razrabotchikov?
1.13) Kak otpravit' soobschenie ob oshibke?
1.14) Kak sravnivat' PostgreSQL s drugimi SUBD?
1.15) Kak okazat' finansovuyu pomosch' PostgreSQL?
Voprosy pol'zovatelej po klientskoj chasti
2002-04-12 17:17:10 +08:00
2.1) Suschestvuyut li ODBC drajvera dlya PostgreSQL?
2.2) Kakie instrumenty suschestvuyut dlya ispol'zovaniya PostgreSQL
cherez Web?
2.3) Est' li u PostgreSQL graficheskij interfejs pol'zovatelya?
2.4) Kakie yazyki mogut vzaimodejstvovat' s PostgreSQL?
Voprosy administrirovaniya
2002-04-12 17:17:10 +08:00
3.1) Kak mne ustanovit' PostgreSQL v mesto otlichnoe ot
2002-04-12 17:17:10 +08:00
/usr/local/pgsql?
3.2) Kogda ya zapuskayu postmaster, ya poluchayu soobschenie Bad
System Call ili soobschenie core dumped. Pochemu?
3.3) Kogda ya pytayus' zapustit' postmaster, ya poluchayu oshibki
IpcMemoryCreate. Pochemu?
3.4) Kogda ya pytayus' zapustit' postmaster, ya poluchayu oshibki
IpcSemaphoreCreate. Pochemu?
3.5) Kak mne upravlyat' soedineniyami s drugih komp'yuterov?
3.6) Kakie nastrojki mne nuzhno sdelat' dlya uluchsheniya
proizvoditel'nosti?
3.7) Kakie vozmozhnosti dlya otladki est' v nalichii?
3.8) Pochemu ya poluchayu soobschenie "Sorry, too many clients" kogda
pytayus' podklyuchit'sya k baze?
3.9) CHto nahoditsya v kataloge pgsql_tmp?
3.10) Pochemu neobhodimo delat' dump i restore pri obnovlenii vypuskov
2002-08-23 10:53:20 +08:00
PostgreSQL?
2002-04-12 17:17:10 +08:00
Voprosy `ekspluatacii
2002-04-12 17:17:10 +08:00
4.1) V chem otlichie mezhdu binarnym i normal'nym kursorom?
4.2) Kak vypolnit' SELECT tol'ko dlya neskol'kih pervyh strochek
zaprosa?
4.3) Kak poluchit' spisok tablic ili drugih komponentov v psql?
4.4) Kak udalit' kolonku iz tablicy?
4.5) Kakovy maksimal'nye razmery dlya zapisej, tablic i bazy dannyh?
4.6) Kak mnogo diskovogo prostranstva v baze dannyh nuzhno dlya
sohraneniya dannyh iz obychnogo tekstovogo fajla?
4.7) Kak mne ubedit'sya, chto suschestvuyut nuzhnye mne tablicy,
indeksy, bazy dannyh i pol'zovateli?
4.8) U menya medlenno rabotayut zaprosy ili ne proishodit
ispol'zovaniya indeksov. Pochemu?
4.9) Kak posmotret' na to, kak optimizator vypolnyaet moj zapros?
4.10) CHto takoe R-tree indeks?
4.11) CHto takoe Genetic Query Optimizer?
4.12) Kak mne vypolnit' poisk regulyarnogo vyrazheniya i poisk
nezavisimyj ot registra bukv poisk regulyarnogo vyrazheniya? Kak mne
ispol'zovat' indeks dlya poiska nezavisimogo ot registra bukv?
4.13) Kak ya mogu opredelit', chto znachenie polya ravno NULL v
kakom-libo zaprose?
4.14) Kakovy otlichiya mezhdu raznymi simvol'nymi tipami?
4.15.1) Kak mne sozdat' pole serial/s-avto-uvelicheniem?
4.15.2) Kak mne poluchit' znachenie pri vstavke SERIAL?
4.15.3) Ne mozhet li poluchit'sya tak, chto ispol'zovanie currval() i
nextval() privedet k zaciklirovaniyu s drugimi pol'zovatelyami?
4.15.4) Pochemu chisla iz moej posledovatel'nosti ne ispol'zuyutsya
snova pri otmene tranzakcii? Pochemu sozdayutsya razryvy pri numeracii
v kolonke, gde ya ispol'zuyu posledovatel'nost'/SERIAL?
4.16) CHto takoe OID? CHto takoe TID?
4.17) CHto oznachayut nekotorye terminy ispol'zuemye v PostgreSQL?
4.18) Pochemu ya poluchayu oshibku "ERROR: Memory exhausted in
2002-04-12 17:17:10 +08:00
AllocSetAlloc()"?
4.19) Kak mne uznat', kakaya versiya PostgreSQL zapuschena?
4.20) Pochemu pri rabote s moim bol'shim ob"ektom ya poluchayu oshibku
2002-04-12 17:17:10 +08:00
"invalid large obj descriptor"?
4.21) Kak mne sozdat' kolonku kotoraya po umolchaniyu budet soderzhat'
tekuschee vremya?
4.22) Pochemu moi podzaprosy, ispol'zuyuschie IN tak medlenno
rabotaeyut?
4.23) Kak vypolnit' vneshnee svyazyvanie?
4.24) Kak vypolnyat' zaprosy, ispol'zuyuschie neskol'ko baz dannyh?
4.25) Kak mne vernut' iz funkcii neskol'ko zapisej?
4.26) Pochemu ya ne mogu nadezhno sozdavat'/udalyat' vremennye tablicy
v funkciyah PL/PgSQL?
4.27) Kakie opcii replikacii suschestvuyut?
4.28) Kakie opcii shifrovaniya suschestvuyut?
Rasshireniya PostgreSQL
2002-04-12 17:17:10 +08:00
5.1) YA napisal funkciyu opredelyaemuyu pol'zovatelem. Kogda ya
zapuskayu ee v psql, pochemu ya poluchayu dump core?
5.2) Kak ya mogu vnesti nekotorye klassnye novye tipy i funkcii v
2002-04-12 17:17:10 +08:00
PostgreSQL?
5.3) Kak mne napisat' C funkciyu, vozvraschayuschuyu zapis'?
5.4) YA izmenil ishodnyj fajl. Pochemu posle perekompilyacii ya ne
vizhu izmenenij?
2002-04-12 17:17:10 +08:00
_________________________________________________________________
Obschie voprosy
2002-04-12 17:17:10 +08:00
1.1) CHto takoe PostgreSQL? Kak proiznositsya `eto nazvanie?
2002-04-12 17:17:10 +08:00
PostgreSQL proiznositsya Post-Gres-Q-L (Post-Gres-K'yu-`El).
PostgreSQL - `eto rasshirenie SUBD POSTGRES, issledovatel'skij
prototip novogo pokoleniya SUBD. PostgreSQL odnovremenno sohranyaet
moschnuyu model' dannyh i obschirnoe kolichestvo tipov POSTGRES, i
zameschaet yazyk zaprosov PostQuel na rasshirennoe podmnozhestvo SQL.
PostgreSQL - `eto svobodnoe i polnost'yu otkrytoe programmnoe
obespechenie.
Razrabotku PostgreSQL vypolnyaet komanda razrabotchikov, vse
uchastniki kotoroj podpisany na spisok rassylki razrabotchikov. V
nastoyaschee vremya, ih koordinatorom yavlyaetsya Mark Fornaj (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.
Avtorami PostgreSQL 1.01 yavlyayutsya `Endryu YU (Andrew Yu) i Dzholi
CHen (Jolly Chen). Mnogie drugie vnesli svoj vklad v perenos na drugie
platformy, testirovanie, otladku i rasshirenie `etogo koda.
Pervonachal'nyj kod Postgres, iz kotorogo poyavilsya PostgreSQL, byl
itogom usilij mnogih akademicheskih studentov, neakademicheskih
studentov i mnozhestva raznyh programmistov, rabotavshih pod
rukovodstvom professora Majkla Stounbrejkera (Michael Stonebraker) v
Kalifornijskom universitete, Berkli.
Pervonachal'noe imya, dannoe v Berkli, bylo Postgres. Kogda v 1995
godu byla dobavlena funkcional'nost' SQL, `eto imya bylo izmeneno na
Postgres95. No i `eto imya bylo izmeneno v konce 1996 na PostgreSQL.
1.2) Kakovy avtorskie prava na PostgreSQL?
PostgreSQL popadaet pod dejstvie sleduyuschego COPYRIGHT:
2002-04-12 17:17:10 +08:00
Sistema Upravleniya Bazami Dannyh PostgreSQL
2002-04-12 17:17:10 +08:00
Portion copyright (c) 1996-2002, PostgreSQL Global Development Group
Portions Copyright (c) 1994-6 Regents of the University of California
2002-04-12 17:17:10 +08:00
Predostavlyayutsya prava na ispol'zovanie, kopirovanie, izmenenie i
rasprostranenie dannogo programmnogo obespecheniya i ego dokumentacii
dlya lyubyh celej, besplatno i bez podpisaniya kakogo-libo
soglasheniya, pri uslovii chto dlya kazhdoj kopii budut predostavleny
dannoe vyshe zamechanie ob avtorskih pravah, tekuschij paragraf i dva
sleduyuschih paragrafa.
KALIFORNIJSKIJ UNIVERSITET NE NESET NIKAKOJ OTVETSTVENNOSTI ZA LYUBYE
POVREZHDENIYA, VKLYUCHAYA POTERYU DOHODA, NANESENNYE PRYAMYM ILI
NEPRYAMYM, SPECIAL'NYM ILI SLUCHAJNYM ISPOL'ZOVANIEM DANNOGO
PROGRAMMNOGO OBESPECHENIYA ILI EGO DOKUMENTACII, DAZHE ESLI
KALIFORNIJSKIJ UNIVERSITET BYL IZVESCHEN O VOZMOZHNOSTI TAKIH
POVREZHDENIJ.
KALIFORNIJSKIJ UNIVERSITET SPECIAL'NO OTKAZYVAZYVAETSYA PREDOSTAVLYAT'
LYUBYE GARANTII, VKLYUCHAYA, NO NE OGRANICHIVAYAS' TOL'KO `ETIMI
GARANTIYAMI: NEYAVNYE GARANTII PRIGODNOSTI TOVARA ILI PRIGODNOSTI DLYA
OTDEL'NOJ CELI. DANNOE PROGRAMMNOE OBESPECHENIE PREDOSTAVLYAETSYA NA
OSNOVE PRICIPA "KAK EST'" I KALIFORNIJSKIJ UNIVERSITET NE OBYAZAN
PREDOSTAVLYAT' SOPROVOZHDENIE, PODDERZHKU, OBNOVLENIYA, RASSHIRENIYA
ILI IZMENENIYA.
Vysheizlozhennoe yavlyaetsya BSD licenziej, klassicheskoj licenziej
programmnogo obespecheniya s otkrytym kodom. `Eta licenziya ne
nakladyvaet ogranichenij na ispol'zovanie ishodnogo koda. Nam
nravitsya `eta licenziya i my ne sobiraemsya eio menyat'.
1.3) Na kakih Unix platformah rabotaet PostgreSQL?
Obychno, PostgreSQL mozhet rabotat' na lyuboj sovremennoj platforme
sovmestimoj s Unix. V instrukcii po ustanovke, vy najdete spisok teh
platform, na kotoryh byli provedeny testovye zapuski PostgreSQL k
momentu vyhoda dannoj versii.
2002-04-12 17:17:10 +08:00
1.4) Suschestvuyut li versii perenesennye ne na Unix sistemy?
2002-04-12 17:17:10 +08:00
Klient
2002-04-12 17:17:10 +08:00
Dlya zapuska na platformah MS Windows vozmozhna kompilyaciya C
biblioteki libpq, psql, drugih interfesov i klientskih prilozhenij. V
`etom sluchae, klient zapuskaetsya na MS Windows i svyazyvaetsya po
TCP/IP s serverom, zapuschennym na odnoj iz podderzhivaemyh Unix
platform. V distributiv vklyuchaetsya fajl win32.mak dlya togo, chtoby
mozhno bylo provesti sborku biblioteki libpq i psql dlya Win32.
PostgreSQL takzhe rabotaet cherez ODBC.
2002-04-12 17:17:10 +08:00
Server
Server BD mozhet byt' zapuschen na Windows NT i Win2k, ispol'zuya
biblioteku Cygwin, razrabotannuyu kompaniej Cygnus dlya perenosa
programmnogo obespecheniya Unix v NT. Smotrite pgsql/doc/FAQ_MSWIN v
distributive ili MS Windows FAQ na
http://www.PostgreSQL.org/docs/faqs/text/FAQ_MSWIN.
PostgreSQL, sportirovannyj special'no dlya MS Win NT/2000/XP v
nastoyaschij moment nachal rabotat'. Podrobnosti tekuschego
sostoyaniya PostgreSQL dlya Windows smotrite na
http://techdocs.postgresql.org/guides/Windows.
Takzhe suschestvuet versiya sportirovannaya pod Novell Netware 6 na
http://forge.novell.com.
2002-04-12 17:17:10 +08:00
1.5) Gde mozhno vzyat' PostgreSQL?
Naprimer, vospol'zovavshis' anonimnym dostupom na ftp sajt PostgreSQL
ftp://ftp.PostgreSQL.org/pub. Spisok zerkal vy najdete na nashem
osnovnom sajte.
1.6) Gde poluchit' podderzhku?
Osnovnoj spisok rassylki: pgsql-general@PostgreSQL.org. V nem mozhno
obsuzhdat' lyubye temy, kasayuschiesya PostgreSQL. CHtoby
podpisat'sya, otprav'te pis'mo po `elektronnoj pochte, v kotorom v
tele pis'ma (ne v teme) napishite sleduyuschie stroki:
2002-04-12 17:17:10 +08:00
subscribe
end
na adres pgsql-general-request@PostgreSQL.org.
2002-04-12 17:17:10 +08:00
Suschestvuet dajzhest spisok. CHtoby podpisat'sya na nego, otprav'te
pis'mo po `elektronnoj pochte na adres:
pgsql-general-digest-request@PostgreSQL.org i v tele pis'ma napishite
strochki strochki:
2002-04-12 17:17:10 +08:00
subscribe
end
Dajzhesty otpravlyayutsya podpischikam, kogda v osnovnom spiske
rassylki nakopitsya okolo 30 kilobajt soobschenij.
2002-04-12 17:17:10 +08:00
Dostupen i spisok rassylki soobschenij ob oshibkah. CHtoby
podpisat'sya na `etot spisok, otprav'te po `elektronnoj pochte pis'mo
na adres pgsql-bugs-request@PostgreSQL.org i v tele pis'ma napishite
strochki strochki:
2002-04-12 17:17:10 +08:00
subscribe
end
Takzhe imeetsya spisok rassylki s diskussiyami razrabotchikov. CHtoby
podpisat'sya na `etot spisok, otprav'te po `elektronnoj pochte pis'mo
na adres pgsql-hackers-request@PostgreSQL.org i v tele pis'ma
napishite strochki strochki:
2002-04-12 17:17:10 +08:00
subscribe
end
Dopolnitel'nye spiski rassylki i infomaciyu o PostgreSQL mozhno najti
na domashnej stranichke PostgreSQL po adresu:
2002-04-12 17:17:10 +08:00
http://www.PostgreSQL.org
Esche suschestvuet IRC kanal na EFNet i OpenProjects, s nazvaniem
#PostgreSQL. YA ispol'zuyu dlya podklyucheniya k `etomu kanalu komandu
Unix irc -c '#PostgreSQL' "$USER" irc.phoenix.net.
2002-04-12 17:17:10 +08:00
Spisok kommercheskoj podderzhki kompanij dostupen na
http://www.ca.PostgreSQL.org/users-lounge/commercial-support.html.
2002-04-12 17:17:10 +08:00
1.7) Kakaya poslednyaya versiya?
2002-04-12 17:17:10 +08:00
Poslednij vypusk PostgreSQL - `eto versiya 7.3.2.
2002-04-12 17:17:10 +08:00
My planiruem vypuskat' novye versii kazhdye chetyre mesyaca.
2002-04-12 17:17:10 +08:00
1.8) Kakaya dokumentaciya imeetsya v nalichii?
2002-04-12 17:17:10 +08:00
V distributiv vklyuchayutsya razlichnye rukovodstva, stranicy
`elektronnogo rukovodstva man i nekotorye malen'kie testovye primery.
Smotrite v katalog /doc. Vy takzhe mozhete prosmatrivat' dokumentaciyu
v Internet po adresu http://www.PostgreSQL.org/docs.
Suschestvuet dve knigi po PostgreSQL dostupnye po adresam
http://www.PostgreSQL.org/docs/awbook.html i
http://www.commandprompt.com/ppbook/. Spisok knig po PostgreSQL,
kotorye mozhno kupit' dostupen po adresu
http://www.ca.PostgreSQL.org/books/. Krome togo, po adresu
http://techdocs.PostgreSQL.org/ vy mozhete najti kollekciyu
tehnicheskih statej posvyaschennyh PostgreSQL.
psql imeet neskol'ko prekrasnyh komand \d dlya otobrazheniya
informacii po tipam, operatoram, funkciyam, agregatam i t.d.
Nash sajt soderzhit esche bol'she informacii.
1.9) Kak najti informaciyu ob izvestnyh oshibkah ili otsutstvuyuschih
vozmozhnostyah?
2002-04-12 17:17:10 +08:00
PostgreSQL podderzhivaet rasshirennyj podklass SQL-92. Smotrite nash
spisok TODO na predmet izvestnyh oshibok, otsutstvuyuschih
vozmozhnostej i buduschih planov.
2002-04-12 17:17:10 +08:00
1.10) Kak mne nauchit'sya SQL?
2002-04-12 17:17:10 +08:00
Kniga po PostgreSQL na http://www.PostgreSQL.org/docs/awbook.html
nauchit SQL. Suschestvuet drugaya kniga po PostgreSQL na
http://www.commandprompt.com/ppbook. Est' prekrasnyj uchebnik na
http://www.intermedia.net/support/sql/sqltut.shtm, na
2002-04-12 17:17:10 +08:00
http://ourworld.compuserve.com/homepages/graeme_birchall/HTM_COOK.HTM,
i na http://sqlcourse.com.
2002-04-12 17:17:10 +08:00
Esche odin uchebnik - `eto kniga "Teach Yourself SQL in 21 Days,
Second Edition" (Osvoj samostoyatel'no SQL za 21 den', Vtoraya
redakciya) na http://members.tripod.com/er4ebus/sql/index.htm
2002-04-12 17:17:10 +08:00
Mnogim iz nashih pol'zovatelej nravitsya kniga The Practical SQL
Handbook, Bowman, Judith S., et al., Addison-Wesley. Drugim nravitsya
2002-04-12 17:17:10 +08:00
The Complete Reference SQL, Groff et al., McGraw-Hill.
1.11) Reshena li v PostgreSQL problema 2000-go goda (Y2K)?
2002-04-12 17:17:10 +08:00
Da, my legko rabotaem s datami posle 2000 goda i pered 2000 godom.
2002-04-12 17:17:10 +08:00
1.12) Kak prisoedinitsya k komande razrabotchikov?
2002-04-12 17:17:10 +08:00
Dlya nachala, skachajte poslednyuyu versiyu ishodnyh tekstov i
prochtite dokumentaciyu razrabotchikov PostgreSQL na nashem sajte ili
v distributive. Zatem, podpishites' na spiski rassylki pgsql-hackers i
pgsql-patches. Dalee, otpravlyajte ispravleniya (patches) vysokogo
kachestva v spisok pgsql-patches.
Suschestvuet ogranichennyj spisok lyudej, kotoryj imeyut privelegiyu
vnosit' izmeneniya v CVS arhiv PostgreSQL. Kazhdyj iz `etih lyudej v
svoe vremya otpravil tak mnogo vysokokachestvennyh ispravlenij, chto
ih bylo nevozmozhno ostavit' bez vnimaniya i oni byli udostoeny
previlegii vnosit' izmeneniya, i my uvereny, chto te ispravleniya,
kotorye oni vnesut budut vysokogo kachestva.
1.13) Kak otpravit' soobschenie ob oshibke??
2002-04-12 17:17:10 +08:00
Pozhalujsta posetite stranichku PostgreSQL BugTool na
http://www.PostgreSQL.org/bugs/bugs.php, na kotoroj predostavleny
detal'nye instrukcii o tom kak otpravit' soobschenie ob oshibke.
2002-04-12 17:17:10 +08:00
Takzhe ne zabud'te posmotret' na ftp://ftp.PostgreSQL.org/pub na
predmet bolee svezhih versij PostgreSQL ili zaplat.
2002-04-12 17:17:10 +08:00
1.14) Kak sravnivat' PostgreSQL s drugimi SUBD?
2002-04-12 17:17:10 +08:00
Suschestvuet neskol'ko metodov sravneniya programmnogo obespecheniya:
vozmozhnosti, proizvoditel'nost', nadezhnost', podderzhka i cena.
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.
2002-04-12 17:17:10 +08:00
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 medlenee
pri operaciyah vstavki/obnovleniya, potomu chto upravlyaem
tranzakciyami. I razumeetsya, MySQL ne imeet kakih-libo
vozmozhnostej iz perechislenyh vyshe, v sekcii Vozmozhnosti. My
delaem upor na nadezhnost' i rasshirennye vozmozhnosti, no my
takzhe prodolzhaem uvelichivat' proizvoditel'nost' s kazhdym
vypuskom. Suschestvuet interesnaya stranichka v Internet,
sravnivayuschaya PostgreSQL i MySQL na
http://openacs.org/philosophy/why-not-mysql.html
2002-04-12 17:17:10 +08:00
Nadezhnost'
My ponimali, chto nasha SUBD dolzhna byt' nadezhnoj ili ona
nichego ne budet stoit'. My staraemsya vypuskat' horosho
proverennyj, stabil'nyj kod, kotoryj soderzhit minimum oshibok.
Kazhdyj vypusk prohodit stadiyu beta-testirovaniya po krajnej
mere v techenii odnogo mesyaca i nasha istoriya vypuskov
pokazyvaet chto my mozhem predostavlyat' stabil'nye, monolitnye
vypuski, kotorye gotovy k produktivnomu ispol'zovaniyu. My
verim, chto my proizvodim proverku ne huzhe, chem u drugih
SUBD.
2002-04-12 17:17:10 +08:00
Podderzhka
Nash spisok rassylki predostavlyaet vozmozhmozhnost' obscheniya
s bol'shoj gruppoj razrabotchikov i pol'zovatelej, kotorye
mogut pomoch' reshit' lyubye voznikshie problemy. V to zhe
vremya, my ne garantiruem kakie-libo ispravleniya, no i
razrabotchiki kommercheskih SUBD ne vsegda delayut
ispravleniya. Pryamoj dostup k razrabotchikam, soobschestvu
pol'zovatelej, rukovodstvam i ishodnym tekstam chasto delayut
podderzhku PostgreSQL prevoshodyaschej drugie SUBD.
Suschestvuet kommercheskaya podderzhka po rezul'tam voznikshih
incidentov, kotoraya dostupna dlya teh komu ona nuzhna.
(Smotrite Sekciyu 1.6.)
2002-04-12 17:17:10 +08:00
Cena
Nash produkt besplaten kak dlya kommercheskogo tak, i ne dlya
kommercheskogo ispol'zovaniya. Vy mozhete dobavlyat' svoj kod v
nash produkt bez ogranichenij, za isklyucheniem teh, chto
opisyvayutsya v nashej licenzii stilya BSD, kotoraya privedena
vyshe.
2002-04-12 17:17:10 +08:00
1.15) Kak okazat' finansovuyu pomosch' PostgreSQL?
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
upravlyaet ej na protyazhenii `etih let.
Kachestvennaya infrastruktura ochen' vazhna dlya proektov s otkrytym
ishodnym kodom. Ona predotvraschaet raskoly, kotorye mogut sil'no
zaderzhat' postupatel'noe dvizhenie proekta.
Razumeetsya, `eta infrastruktura ne yavlyaetsya deshevoj. Suschestvuet
nekotoroe kolichestvo ezhemesyachnyh i odnorazovyh rashodov, kotorye
trebuyut deneg. Esli vy ili vasha kompaniya imeet den'gi, kotorye
mozhno peredat' v pomosch' nashim usiliyam, pozhalujsta posetite
stranichku https://store.pgsql.com/shopping/ i sdelajte svoj vklad.
Hotya na stranichke govoritsya o PostgreSQL, Inc, punkt
"contributions" prednaznachen isklyuchitel'no dlya podderzhki proekta
PostgreSQL i ne peredaetsya kakoj-libo konkretnoj kompanii. Esli
hotite, to mozhete `eto proverit', napisav pis'mo na kontaktnyj adres.
2002-04-12 17:17:10 +08:00
_________________________________________________________________
Voprosy pol'zovatelej po klientskoj chasti
2002-04-12 17:17:10 +08:00
2.1) Suschestvuyut li ODBC drajvera dlya PostgreSQL?
2002-04-12 17:17:10 +08:00
Suschestvuet dva ODBC drajvera, PsqlODBC i OpenLink ODBC.
2002-04-12 17:17:10 +08:00
Vy mozhete skachat' PsqlODBC s
http://gborg.postgresql.org/project/psqlodbc/projdisplay.php.
2002-04-12 17:17:10 +08:00
OpenLink ODBC mozhno vzyat' na http://www.openlinksw.com. `Etot
drajver rabotaet s ih standartnym klientskim programmnym
obespecheniem, ispol'zuyuschim ODBC, i takim obrazom, ODBC drajvery
dlya PostgreSQL dostupny dlya kazhdoj iz podderzhivaemyh imi platform
(Win, Mac, Unix, VMS).
2002-04-12 17:17:10 +08:00
Vozmozhno oni budut prodavat' svoj produkt tem komu nuzhna
kommercheskaya podderzhka, no besplatnaya versiya vsegda budet
dostupna. Pozhalujsta, napravlyajte voprosy na adres
postgres95@openlink.co.uk.
2002-04-12 17:17:10 +08:00
2.2) Kakie instrumenty suschestvuyut dlya ispol'zovaniya PostgreSQL cherez
Web?
2002-04-12 17:17:10 +08:00
Prekrasnoe vvedenie vo vzaimodejstvie baz dannyh i Web mozhno najti
na: http://www.webreview.com
2002-04-12 17:17:10 +08:00
Dlya integracii s Web, odnim iz prevoshodnyh instrumentov yavlyaetsya
PHP. Domashnyaya stanichka http://www.php.net.
2002-04-12 17:17:10 +08:00
Dlya kompleksnyh reshenij, mnogie pol'zuyutsya Perl interfejsom i
CGI.pm ili mod_perl.
2002-04-12 17:17:10 +08:00
2.3) Est' li u PostgreSQL graficheskij interfejs pol'zovatelya?
2002-04-12 17:17:10 +08:00
Da, suschestvuet neskol'ko graficheskih interfejsov dlya PostgreSQL.
2003-02-14 22:05:00 +08:00
`Eto PgAccess (http://www.pgaccess.org, PgAdmin II
(http://www.pgadmin.org, Win32-only), RHDB Admin (
http://sources.redhat.com/rhdb/) i Rekall (
http://www.thekompany.com/products/rekall/, kommercheskij). Takzhe
est' PHPPgAdmin ( http://phppgadmin.sourceforge.net/) - interfejs k
PostgreSQL, osnovannyj na Web.
2.4) Kakie yazyki mogut vzaimodejstvovat' s PostgreSQL?
2002-04-12 17:17:10 +08:00
Kakie-libo interfejsy dlya PostgreSQL suschestvuyut dlya bol'shinstva
populyarnyh yazykov programmirovaniya. Posmotrite spisok modulej
rasshireniya dlya teh yazykov programmirovaniya, kotorymi vy
pol'zuetes'.
Sleduyuschie interfejsy vklyuchayutsya v distributiv PostgreSQL:
2002-04-12 17:17:10 +08:00
* C (libpq)
* Embedded C (ecpg)
* Java (jdbc)
* Python (PyGreSQL)
* TCL (libpgtcl)
2002-08-23 10:53:20 +08:00
Dopolnitel'nye interfejsy dostupny po adresu
http://gborg.PostgreSQL.org v sekcii Drivers/Interfaces.
2002-04-12 17:17:10 +08:00
_________________________________________________________________
Voprosy administrirovaniya
2002-04-12 17:17:10 +08:00
3.1) Kak mne ustanovit' PostgreSQL v mesto otlichnoe ot /usr/local/pgsql?
Zadajte opciyu --prefix kogda zapuskaete configure.
3.2) Kogda ya zapuskayu postmaster, ya poluchayu soobschenie Bad System
Call ili soobschenie core dumped. Pochemu?
`Eto mozhet byt' vyzvano raznymi problemami, no pervoe, chto nuzhno
sdelat' - `eto ubedit'sya v tom, chto v vashem yadre ustanovleno
rasshirenie System V. PostgreSQL trebuet, chtoby yadro podderzhivalo
razdelyaemuyu pamyat' i semafory.
3.3) Kogda ya pytayus' zapustit' postmaster, ya poluchayu oshibki
IpcMemoryCreate. Pochemu?
Libo u vas v yadre nepravil'nye nastrojki razdelyaemoj pamyati, libo
vashemu yadru nuzhno bol'shee kolichestvo dostupnoj razdelyaemoj
pamyati. Te konkretnye dejstviya, kotorye vam nuzhno proizvesti
zavisyat ot arhitektury vashej mashiny i ot togo kak mnogo buferov i
backend processov vy nastroili dlya postmaster. Dlya bol'shinstva
sistem, s kolichestvom buferov i processov po umolchaniyu, neobhodimyj
minimum - `eto okolo 1 megabajta. Podrobnosti o razdelyaemoj pamyati i
semaforah smotrite v Rukovodstve administratora PostgreSQL.
3.4) Kogda ya pytayus' zapustit' postmaster, ya poluchayu oshibki
IpcSemaphoreCreate. Pochemu?
Esli `eto soobschenie IpcSemaphoreCreate: semget failed (No space left
on device) to nastrojki vashego yadra takovy, chto emu ne hvataet
semaforov. Postgres trebuet odin semafor na potencial'nyj backend
process. Vremennym resheniem yavlyaetsya zapusk postmaster s
nastrojkami na mesh'shee kolichestvo backend processov. Ispol'zujte -N
s znacheniem men'shim chem 32, kotoroe prinyato po umolchaniyu. Bolee
pravil'noe reshenie - `eto uvelichit' znacheniya SEMMNS i SEMMNI v
nastrjkah yadra.
Neispravnye semafory takzhe mogut privesti k padeniyu SUBD vo vremya
dostupa k baze dannyh.
Esli vy poluchili kakoe-libo drugoe soobschenie ob oshibke, to vpolne
vozmozhno, chto v vashem yadre voobsche ne nastroena podderzhka
semaforov. Smotrite podrobnosti o razdelyaemoj pamyati i semaforah v
Rukovodstve Administratora PostgreSQL.
3.5) Kak mne upravlyat' soedineniyami s drugih komp'yuterov?
Po umolchaniyu, PostgreSQL razreshaet tol'ko soedineniya na lokal'noj
mashine cherez sokety domena Unix. Drugie mashiny ne smogut
podklyuchit'sya k baze poka dlya postmaster ne budet zadan flag -i i
poka ne budet razreshena host-avtorizaciya v fajle
$PGDATA/pg_hba.conf. `Eti dejstviya delayut vozmozhnymi TCP/IP
soedineniya.
3.6) Kakie nastrojki mne nuzhno sdelat' dlya uluchsheniya
proizvoditel'nosti?
Nesomnenno, indeksy mogut uvelichit' skorost' vypolneniya zaprosov.
Komanda EXPLAIN pozvolyaet vam posmotret' kak PostgreSQL
interpretiruet vash zapros i kakie indeksy ispol'zuyutsya.
Esli vy vypolnyaete mnogo operatorov INSERT, rassmotrite vozmozhnost'
vypolnyat' ih v bol'shoj pachke, ispol'zuya komandu COPY. `Eto
znachitel'no bystree, chem otdel'nye INSERT. Vo-vtoryh, operatory vne
bloka tranzakcii BEGIN WORK/COMMIT sami vypolnyayut tranzakciyu.
Podumajte nad vypolneniem neskol'kih operatorov v odnom bloke
tranzakcii. `Eto umen'shit kolichestvo tranzakcij. Takzhe, zadumajtes'
nad udaleniem i peresozdaniem indeksov, kogda vy vypolnyaete bol'shie
izmeneniya dannyh.
Suschestvuet neskol'ko opcij nastrojki. Vy mozhete zapretit' fsync()
pri starte postmaster s opciej -o -F. `Eto predotvratit vyzovy
fsync(), kotorye privodyat k sbrosu dannyh na disk posle kazhdoj
tranzakcii.
Vy mozhete takzhe ispol'zovat' dlya postmaster opciyu -B dlya
uvelicheniya kolichestva buferov razdelyaemoj pamyati, kotoraya
ispol'zuetsya backend processami. Esli vy sdelaete znachenie `etogo
parametra slishkom bol'shim, to postmaster mozhet ne zapustitsya
potomu chto vy ischerpaete ogranichenie yadra na ob"em razdelyaemoj
pamyati. Kazhdyj bufer imeet razmer v 8 kilobajt i po umolchaniyu
vydelyaetsya 64 bufera.
Vy mozhete takzhe ispol'zovat' backend opciyu -S dlya uvelicheniya
maksimal'nogo kolichestva pamyati, kotoroe ispol'zuetsya backend
processom dlya vremennyh sortirovok. Znachenie dlya opcii -S zadaetsya
v kilobajtah i po umolchaniyu ravno 512 (t.e. 512K).
Vy takzhe mozhete ispol'zovat' komandu CLUSTER dlya gruppirovki dannyh
v tablicah na sovpadayuschij indeks. Podrobnosti smotrite na stranice
rukovodstva po komande CLUSTER.
3.7) Kakie vozmozhnosti dlya otladki est' v nalichii?
PostgreSQL imeet neskol'ko vozmozhnostej, pozvolyayuschie poluchit'
informaciyu o sostoyanii, kotoraya mozhet byt' ispol'zovana v
otladochnyh celyah.
Vo-pervyh, pri zapuske configure s opciej --enable-cassert, mnogie
vyzovy assert() pozvolyayut otslezhivat' rabotu backend processa i
ostanovku programmy pri vozniknovenii kakih-libo neozhidannostej.
I postmaster, i postgres imeyut neskol'ko otladochnyh opcij.
Vo-pervyh, pri zapuske postmaster, ubedites', chto standartnyj vyvod i
vyvod oshibok osuschestvlyayutsya v fajl zhurnala:
2002-04-12 17:17:10 +08:00
cd /usr/local/pgsql
./bin/postmaster >server.log 2>&1 &
`Eto privedet k poyavleniyu fajla server.log v glavnom kataloge
PostgreSQL. `Etot fajl soderzhit poleznuyu informaciyu o problemah ili
oshibkah, voznikshih na servere. Postmaster imeet opciyu -d, kotoraya
pozvolyaet poluchat' pri protokolirovanii bolee detal'nuyu infrmaciyu.
Dlya opcii -d ukazyvaetsya chislo, kotoroe zadaet uroven' otladki.
Bud'te ostorozhny, tak kak vysokij uroven' otladki privodit k
generacii fajlov zhurnala bol'shogo razmera.
Esli postmaster ne zapuschen, vy mozhete zapustit' postgres backend iz
komandnoj stroki i vvesti vash operator SQL napryamuyu. `Eto
rekomenduetsya tol'ko dlya celej otladki. Zametim, chto v `etom
rezhime, zapros zavershaetsya simvolom novoj stroki, a ne tochkoj s
zapyatoj. Esli vy proizvodili kompilyaciyu s otladochnymi simvoloami,
vy mozhete ispol'zovat' lyuboj otladchik, chtoby posmotret', chto
sluchilos'. Poskol'ku backend zapuskaetsya ne iz postmaster, on ne
zapuskaetsya v identichnom okruzhenii i znachit problemy iteracij
blokirovok/backend ne mogut byt' vosproizvedeny.
Esli postmaster zapuschen, zapustite psql v odnom okne, zatem najdite
PID processa postgres, ispol'zuemyj psql. Ispol'zujte otdadchik dlya
podklyucheniya k postgres PID. Vy mozhete ustanovit' tochki
preryvaniya v otladchike i zapustit' zapros iz psql. Esli vy
proizvodite otladku zapuska postgres, vy mozhete ustanovit'
PGOPTIONS="-W n", i zatem zapustit' psql. `Eta opciya privodit k
zaderzhke processa zapuska na n sekund, v techenie kotoryh vy mozhete
podklyuchit' k processu otladchik, ustanovit' lyubye tochki
preryvaniya i prodolzhit' zapusk.
Programma postgres imeet opcii -s, -A, i -t kotorye mogut byt' ochen'
poleznymi dlya otladki i izmereniya proizvoditel'nosti.
Vy takzhe mozhete skompilirovat' PostgreSQL s profilirovaniem dlya
togo, chtoby uvidet' kakie funkcii skol'ko vremeni vypolnyayutsya.
Fajly profilirovaniya backend'a nahodyatsya v kataloge
pgsql/data/base/dbname. Fajl profilirovaniya klienta budet pomeschen v
tekuschij katalog klienta. V Linux dlya vypolneniya profilirovaniya
trebuetsya kompilyacii s -DLINUX_PROFILE.
3.8) Pochemu ya poluchayu soobschenie "Sorry, too many clients" kogda
pytayus' podklyuchit'sya k baze?
Vam nuzhno uvelichit' ogranichenie na kolichestvo konkuretnyh backend
processov pri zapuske postmaster.
Po umolchaniyu ustanovlen limit na 32 processa. Vy mozhete uvelichit'
`etot limit perezapustiv postmaster s nuzhnym znacheniem processov,
kotoroe ukazyvaetsya v opcii -N ili izmeniv fajl postgresql.conf.
Zametim, chto esli vy zadadite v opcii -N znachenie bol'she 32, to vy
takzhe dolzhny uvelichit' znachenie v opcii -B kotoroe po umolchaniyu
ustanovleno v 64; Znachenie opcii -B dolzhno byt' po krajnej mere
vdvoe bol'she znacheniya opcii -N, i vozmozhno eschio bol'she dlya
luchshej proizvoditel'nosti. Dlya bol'shego kolichestva backend
processov, vam takzhe neploho bylo by uvelichit' nekotorye parametry
yadra Unix. `Eto takie parametry, kak maksimal'noe kolichestvo blokov
razdelyaemoj pamyati, SHMMAX; maksimal'noe kolichestvo semaforov,
SEMMNS i SEMMNI; maksimal'noe kolichestvo processov, NPROC;
maksimal'noe kolichestvo processov na pol'zovatelya, MAXUPRC; i
maksimal'noe kolichestvo otkrytyh fajlov, NFILE i NINODE. Prichina
sozdaniya ogranicheniya na kolichestvo backend processov kak raz i
sostoit v tom, chtoby vashej sisteme hvatilo resursov.
3.9) CHto nahoditsya v kataloge pgsql_tmp?
Dannyj katalog soderzhit vremennye fajly, generiruemye obrabotchikom
zaprosa. Naprimer, esli dlya vypolneniya ORDER BY nuzhna sortirovka i
`eta sortirovka trebuet pamyati bol'she, chem dopuskaet parametr -S u
backend'a, to dlya hraneniya dopolnitel'nyh dannyh sozdayutsya
vremennye fajly.
`Eti vremennye fajly dolzhny udalyat'sya avtomaticheski, no `etogo
mozhet ne proizojti, esli backend ruhnul vo vremya sortirovki. Ostanov
i zapusk servernogo processa obespechit ih udalenie iz kataloga.
2002-08-23 10:53:20 +08:00
3.10) Pochemu neobhodimo delat' dump i restore pri obnovlenii vypuskov
PostgreSQL?
Razrabotchiki PostgreSQL delayut tol'ko nebol'shie izmeneniya mezhdu
podvypuskami. Takim obrazom obnovlenie s versii 7.2 do 7.2.1 ne
trebuet vypolneniya dump i restore. Odnako pri vyhode ocherednogo
vypuska (t.e. pri obnovlenii naprimer, s 7.2 na 7.3) chasto menyaetsya
vnutrennij format sistemnyh tablic i fajlov dannyh. `Eti izmeneniya
chasto nosyat kompleksnyj harakter, tak chto net vozmozhnosti
obespechit' obratnuyu sovmestimost' fajlov dannyh. Vypolenie dump
pozvolyaet poluchit' dannye v obschem formate, kotoryj zatem mozhet
byt' zagruzhen pri ispol'zovanii novogo vnutrennego formata.
V teh vypuskah, gde format dannyh na diske ne menyaetsya, dlya
provedeniya obnovleniya mozhet byt' ispol'zovan scenarij pg_upgrade
bez ispol'zovaniya dump/restore. Kommentarii k vypusku govorit kogda
mozhno ispol'zovat' pg_upgrade dlya `etogo vypuska.
2002-04-12 17:17:10 +08:00
_________________________________________________________________
Voprosy `ekspluatacii
2002-04-12 17:17:10 +08:00
4.1) V chem otlichie mezhdu binarnym i normal'nym kursorom?
2002-04-12 17:17:10 +08:00
Smotrite opisanie na stranicah rukovodstva posvyaschennym DECLARE.
2002-04-12 17:17:10 +08:00
4.2) Kak vypolnit' SELECT tol'ko dlya neskol'kih pervyh strochek zaprosa?
2002-04-12 17:17:10 +08:00
Smotrite stanicu rukovodstva posvyaschennuyu FETCH ili ispol'zujte
SELECT ... LIMIT....
2002-04-12 17:17:10 +08:00
Dazhe esli vy hotite poluchit' tol'ko pervye neskol'ko zapisej, budet
vypolnen ves' zapros. Rassmotrim zapros, kotoryj imeet ORDER BY. Esli
est' kakoj-libo indeks, kotoryj sovpadaet s ORDER BY, PostgreSQL
mozhet vydat' tol'ko neskol'ko pervyh zaproshennyh zapisej ili mozhet
vypolnyat' zapros poka ne budut vydany zhelaemye zapisi.
2002-04-12 17:17:10 +08:00
4.3) Kak poluchit' spisok tablic ili drugih komponentov v psql?
2002-04-12 17:17:10 +08:00
Vy mozhete posmotret' ishodnyj kod psql v fajle
pgsql/src/bin/psql/describe.c. On soderzhit komandy SQL kotorye
generiruyutsya pri vvode v psql komand, nachinayuschihsya s obratnoj
kosoj cherty. Vy takzhe moezhete zapustit' psql s opciej -E tak,
chtoby `eta programma vydavala zaprosy, kotorye ona ispol'zuet dlya
vypolneniya zadannyh vami komand.
4.4) Kak udalit' kolonku iz tablicy?
2002-04-12 17:17:10 +08:00
`Eta funkcional'nost' byla dobavlena v vypusk 7.3 s operatorom ALTER
TABLE DROP COLUMN. V rannih versiyah, mozhno sdelat' tak:
BEGIN;
LOCK TABLE old_table;
SELECT ... -- vyborka vseh kolonok za isklyucheniem toj, kotoruyu hotite u
dalit'
2002-04-12 17:17:10 +08:00
INTO TABLE new_table
FROM old_table;
DROP TABLE old_table;
ALTER TABLE new_table RENAME TO old_table;
COMMIT;
2002-04-12 17:17:10 +08:00
4.5) Kakovy maksimal'nye razmery dlya zapisej, tablic i bazy dannyh?
Suschestvuyut sleduyuschie ogranicheniya:
Maksimal'nyj razmer bazy? neogranichen (suschestvuyut bazy na
4 TB)
Maksimal'nyj razmer tablicy? 16 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
2002-04-12 17:17:10 +08:00
Razumeetsya, ponyatie "neogranicheno" na samom dele ogranichivaetsya
dostupnym diskovym prostranistvom i razmerami pamyati/svoppinga. Kogda
znacheniya perechislennye vyshe neopravdano bol'shie, mozhet
postradat' proizvoditel'nost'.
Maksimal'nyj razmer tablicy v 16 TB ne trebuet chtoby operacionnaya
sistema podderzhivala fajly bol'shih razmerov. Bol'shie tablicy
hranyatsya kak mnozhestvo fajlov razmerom v 1 GB, tak chto
ogranicheniya, kotorye nakladyvaet fajlovaya sistema ne vazhny.
Maksimal'nyj razmer tablicy i maksimal'noe kolichestvo kolonok mogut
byt' uvelicheny, esli razmer bloka po umolchaniyu budet uvelichen do
32k.
4.6) Kak mnogo diskovogo prostranstva v baze dannyh nuzhno dlya sohraneniya
dannyh iz obychnogo tekstovogo fajla?
SUBD PostgreSQL mozhet potrebovat'sya diskovogo prostranstva do 5 raz
bol'she dlya sohraneniya dannyh iz prostogo tekstovogo fajla.
V kachestve primera, rassmotrim fajl v 100,000 strok v kazhdoj, iz
kotoryh celoe chislo i tekstovoe opisanie. Pri `etom dlina teksta, v
srednem, sostavlyaet 20 bajt. Razmer prostogo fajla sostavit 2.8 MB.
Razmer bazy PostgreSQL, soderzhaschej `eti zhe dannye sostavit
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
2002-04-12 17:17:10 +08:00
----------------------------------------
64 bajt na zapis'
2002-04-12 17:17:10 +08:00
Razmer stranicy dannyh v PostgreSQL sostavlyaet 8192 bajt (8 KB), tak chto:
2002-04-12 17:17:10 +08:00
8192 bajt na stranicu
------------------- = 128 zapisej na stranicu BD (s okrugleniem)
64 bajt na zapis'
2002-04-12 17:17:10 +08:00
100000 strok dannyh
-------------------- = 782 stranicy v BD
128 zapisej na stranicu
2002-04-12 17:17:10 +08:00
782 stranicy BD * 8192 bajt na stranicu = 6,406,144 bajt (6.4 MB)
2002-04-12 17:17:10 +08:00
Indeksy ne trebuyut tak mnogo, no poskol'ku oni sozdayutsya dlya
bol'shogo kolichestva dannyh, oni takzhe mogut byt' veliki.
Znacheniya NULL sohranyayutsya v bitah i po`etomu oni zanimayut ochen'
malo mesta.
4.7) Kak mne ubedit'sya, chto suschestvuyut nuzhnye mne tablicy, indeksy,
bazy dannyh i pol'zovateli?
psql imeet neskol'ko komand, nachinayuschihsya s obratnoj kosoj
cherty, dlya togo chtoby prosmatrivat' takuyu informaciyu. Ispol'zujte
\? dlya togo, chtoby uvidet' `eti komandy. Takzhe suschestvuyut
sistemnye tablicy, imya kotoryh nachinaetsya na pg_ i v kotoryh takzhe
soderzhitsya `eta informaciya. Eschio, psql -l pokazhet spisok vseh
baz dannyh.
Takzhe smotrite fajl pgsql/src/tutorial/syscat.source. V nem
predstavleny mnogie operatory SELECT kotorye nuzhny dlya polucheniya
informacii iz sistemnyh tablic bazy dannyh.
4.8) U menya medlenno rabotayut zaprosy ili ne proishodit ispol'zovaniya
indeksov. Pochemu?
Indeksy ne ispol'zuyutsya dlya kazhdogo zaprosa avtomaticheski. Oni
ispol'zuyutsya tol'ko esli tablica bol'she minimal'nogo razmera i
zapros vybiraet tol'ko malen'kij procent zapisej v tablice. Tak
ustroeno, potomu chto dostup k disku s primeneniem randomizacii pri
skanirovanii indeksov mozhet byt' medlennee, chem prostoe chtenie
tablicy ili ee posledovatel'noe skanirovanie.
CHtoby opredelit' neobhodimost' ispol'zovaniya indeksa dlya kakoj-libo
tablicy, PostgreSQL dolzhen imet' statistiku po `etoj tablice. `Eta
statistika sobiraetsya pri ispol'zovanii VACUUM ANALYZE ili prosto
ANALYZE. Ispol'zuya statistiku, optimizator uznaet o tom kak mnogo
zapisej v tablice i esli on dolzhen ispol'zovat' indeksy, to on mozhet
prinimat' luchshie resheniya. Statistika takzhe vliyaet na opredelenie
optimal'nogo poryadka svyazyvaniya i metoda svyazyvaniya. Sbor
statistiki dolzhen periodicheski vypolnyatsya pri izmenenii
soderzhimogo tablicy.
Obychno indeksy ne ispol'zuyutsya dlya ORDER BY ili dlya vypolneniya
svyazyvanij. Posledovatel'nyj perebor sleduyuschij za yavnoj
sortirovkoj obychno bystree, chem poisk po indeksam v bol'shoj
tablice. Odnako, ORDER BY chasto kombiniruetsya s LIMIT i v `etom
sluchae indeks budet ispol'zovat'sya, poskol'ku pri vypolnenii budet
vozvraschat'sya nebol'shaya chast' tablicy. Fakticheski MAX() i MIN()
ne ispol'zuyut indeksy, no indeks ispol'zuetsya pri postroenii
zaprosov s ORDER BY i LIMIT:
2002-08-23 10:53:20 +08:00
SELECT col
FROM tab
ORDER BY col [ DESC ]
LIMIT 1;
2002-08-23 10:53:20 +08:00
2003-02-14 22:05:00 +08:00
Esli vam kazhetsya, chto optimizator nekorretno vybiraet
posledovatel'nyj perebor, ispol'zujte SET enable_seqscan TO 'off' i
zapustite testy, chtoby uvidet', ne stalo-li skanirovanie indeksov
bystree.
Kogda ispol'zuyutsya operacii s shablonami, naprimer LIKE ili ~,
indeksy mogut byt' ispol'zovany v sleduyuschih sluchayah:
* Nachalo stroki poiska dolzhno sovpadat' s nachalom iskomoj stroki,
t.e.:
+ LIKE shablony ne dolzhny nachinat'sya s %..
+ ~ shablony regulyarnyh vyrazhenij dolzhna nachinat'sya na ^.
* Stroka poiska ne dolzhna nachinat'sya s simvola klassa, t.e.
[a-e].
* Poisk nezavisimyj ot registra, takoj kak ILIKE i ~* ne ispol'zuet
indeksy. Vmesto nego, ispol'zujte funkcional'nye indeksy, kotorye
opisyvayutsya v sekcii 4.12.
* Vo vremya initdb dolzhna ispol'zovat'sya lokal' po umolchaniyu C.
2002-08-23 10:53:20 +08:00
4.9) Kak posmotret' na to, kak optimizator vypolnyaet moj zapros?
2002-04-12 17:17:10 +08:00
Smotrite stranicu rukovodstva posvyaschennuyu EXPLAIN.
2002-04-12 17:17:10 +08:00
4.10) CHto takoe R-tree indeks?
2002-04-12 17:17:10 +08:00
R-tree indeks ispol'zuetsya dlya indeksirovaniya prostranstvennyh
dannyh. Indeks h`esha ne mozhet upravlyat' poiskami diapazona. B-tree
indeks upravlyaet tol'ko poiskami diapazona v odnom izmerenii. R-tree
indeks mozhet upravlyat' mnogorazmernymi dannymi. Naprimer, esli
R-tree indeks mozhet byt' vstroen v atribut tipa point, to sistema
mozhet bolee `effektivno otvetit' na zapros tipa "vybrat' vse tochki
vnutri zadannogo chetyrehugol'nika."
2002-04-12 17:17:10 +08:00
Kanonicheskij istochnik, opisyvayuschij pervonachal'noe sozdanie
R-tree `eto:
2002-04-12 17:17:10 +08:00
Guttman, A. "R-trees: A Dynamic Index Structure for Spatial
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
2002-04-12 17:17:10 +08:00
Database Systems".
Vstroennnye R-tree mogut upravlyat' poligonami i boksami. V teorii,
R-tree mogut byt' rasshireny dlya upravleniya bol'shim kolichestvom
izmerenij. Na praktike, rasshirenie R-tree trebuet nekotoryh usilij i
u nas, v dannyj moment, net kakoj-libo dokumentacii o tom, kak `eto
sdelat'.
2002-04-12 17:17:10 +08:00
4.11) CHto takoe Genetic Query Optimizer?
2002-04-12 17:17:10 +08:00
Modul' GEQO proizvodit bystruyu optimizaciyu zaprosa, kogda proishodit
svyazyvanie mnogih tablic cherez Genetic Algorithm (GA). `Eto
pozvolyaet upravlyat' bol'shimi zaprosami na svyazyvanie cherez
neistoschayuschij poisk.
4.12) Kak mne vypolnit' poisk regulyarnogo vyrazheniya i poisk nezavisimyj
ot registra bukv poisk regulyarnogo vyrazheniya? Kak mne ispol'zovat'
indeks dlya poiska nezavisimogo ot registra bukv?
2002-04-12 17:17:10 +08:00
Operator ~ proizvodit poisk regulyarnogo vyrazheniya, a operator ~*
proizvodit nezavisimyj ot registra bukv poisk regulyarnogo
vyrazheniya. Nezavisimyj ot registra variant LIKE nazyvaetsya ILIKE.
2002-04-12 17:17:10 +08:00
Nezavisimoe ot registra sravnenie obychno vyrazhaetsya tak:
2002-04-12 17:17:10 +08:00
SELECT *
FROM tab
WHERE lower(col) = 'abc';
2002-04-12 17:17:10 +08:00
`Eta konstrukciya ne budet ispol'zovat' standartnyj indeks. Odnako,
esli vy sozdadite funkcional'nyj indeks, on budet ispol'zovan:
CREATE INDEX tabindex ON tab (lower(col));
2002-04-12 17:17:10 +08:00
4.13) Kak ya mogu opredelit', chto znachenie polya ravno NULL v kakom-libo
zaprose?
2002-04-12 17:17:10 +08:00
Vy prosto sravnivaete znachenie s IS NULL i IS NOT NULL.
2002-04-12 17:17:10 +08:00
4.14) Kakovy otlichiya mezhdu raznymi simvol'nymi tipami?
2002-04-12 17:17:10 +08:00
Tip Vnutrennee imya Zamechaniya
2002-04-12 17:17:10 +08:00
--------------------------------------------------
VARCHAR(n) varchar razmer zadaet maksimal'nuyu dlinu, net zapolnen
iya
2003-02-14 22:05:00 +08:00
CHAR(n) bpchar zapolnyaetsya pustotoj do fiksirovannoj dliny
TEXT text net zadavaemogo verhnego ogranicheniya ili dlin
y
BYTEA bytea massiv bajt peremennoj dliny (mozhno ispol'zova
t' null-bajt bez opaski)
"char" char odin simvol
2002-04-12 17:17:10 +08:00
Vnutrennee imya vy mozhete uvidet', kogda smotrite sistemnye katalogi
i v nekotoryh soobscheniyah ob oshibkah.
Pervye chetyre tipa yavlyayutsya "varlena" tipami (t.e., pervye
chetyre bajta na diske yavlyayutsya dlinnoj, za kotoroj sleduyut
dannye). Takim obrazom, fakticheski ispol'zuemoe prostranstvo bol'she,
chem oboznachennyj razmer. Odnako, `eti tipy dannyh takzhe poddayutsya
szhatiyu ili mogut byt' sohraneny ne v strokom vide cherez TOAST, tak
chto zanimaemoe diskovoe prostranstvo mozhet takzhe byt' i men'she,
chem ozhidalos'.
2003-02-14 22:05:00 +08:00
VARCHAR(n) - `eto luchshee reshenie, kogda nuzhno hranit' stroki
peremennoj dliny, ne prevyshayuschie opredelennogo razmera. TEXT -
`eto luchshee reshenie dlya strok neogranichennoj dliny, s maksimal'no
dopustimoj dlinoj v 1 gigabajt.
CHAR(n) - `eto luchshee reshenie dlya hraneniya strok, kotorye obychno
2003-02-14 22:05:00 +08:00
imeyut odinakovuyu dlinu. CHAR(n) zapolnyaetsya pustotoj do zadannoj
dliny, v to vremya kak VARCHAR(n) hranit tol'ko simvoly, iz kotoryh
sostoit stroka. BYTEA ispol'zuetsya dlya hraneniya binarnyh dannyh,
znacheniya kotoryh mogut vklyuchat' NULL bajty. Vse tipy opisannye
zdes', imeyut shodnye harakteristiki proizvoditel'nosti.
4.15.1) Kak mne sozdat' pole serial/s-avto-uvelicheniem?
PostgreSQL podderzhivaet tip dannyh SERIAL. On avtomaticheski sozdaet
posledovatel'nost' i indeks dlya kolonki. Naprimer:
2002-04-12 17:17:10 +08:00
CREATE TABLE person (
id SERIAL,
name TEXT
);
avtomaticheski transliruetsya v:
2002-04-12 17:17:10 +08:00
CREATE SEQUENCE person_id_seq;
CREATE TABLE person (
id INT4 NOT NULL DEFAULT nextval('person_id_seq'),
name TEXT
);
CREATE UNIQUE INDEX person_id_key ON person ( id );
Smotrite podrobnosti o posledovatel'nostyah na stranice rukovodstva
posvyaschennoj create_sequence. Vy takzhe mozhete ispol'zovat' kazhdoe
pole OID v zapisi kak unikal'noe znachenie. Odnako, esli vam nuzhen
damp i perezagruzka bazy dannyh, vam neobhodimo ispol'zovat' komandu
pg_dump s opciej -o ili opciyu COPY WITH OIDS dlya sohraneniya
znachenij polya OID.
4.15.2) Kak mne poluchit' znachenie pri vstavke SERIAL?
Odin iz sposobov sostoit v poluchenii sleduyuschego znacheniya SERIAL
iz ob"ekta sequence s pomosch'yu funkcii nextval() pered vstavkoj i
zatem vstavlyat' `eto znachenie yavno. Ispol'zujte tablicu-primer v
4.15.1, primer v psevdoyazyke pokazhet kak `eto delaetsya:
new_id = execute("SELECT nextval('person_id_seq')");
execute("INSERT INTO person (id, name) VALUES (new_id, 'Blaise Pascal')");
2002-04-12 17:17:10 +08:00
Zatem vy dolzhny takzhe sohranit' novoe znachenie v peremennoj new_id
dlya ego ispol'zovaniya v drugih zaprosah (naprimer takih kak vneshnij
klyuch dlya tablicy person). Zametim, chto imya avtomaticheski
sozdannogo ob"ekta SEQUENCE budet <table>_<serialcolumn>_seq, gde
table i serialcolumn yavlyayutsya sootvetstvenno imenami vashej
tablicy i vashej kolonki SERIAL.
V kachestve al'ternativy, vy mozhete poluchit' naznachennoe znachenie
SERIAL s pomosch'yu funkcii currval() posle provedeniya obychnoj
operacii vstavki, naprimer
execute("INSERT INTO person (name) VALUES ('Blaise Pascal')");
new_id = execute("SELECT currval('person_id_seq')");
2002-04-12 17:17:10 +08:00
I nakonec, vy mozhete ispol'zovat' znachenie OID, vozraschaemoe iz
opertora INSERT chtoby uvidet' znachenie po umolchaniyu, chto
predpolozhitel'no yavlyaetsya naimenee perenosimym na drugie platformy
resheniem. V Perl, ispol'zuya DBI s modulei Edmund Mergl'ya DBD::Pg,
znachenie oid stanovitsya dostupnym cherez $sth->{pg_oid_status} posle
2002-04-12 17:17:10 +08:00
$sth->execute().
4.15.3) Ne mozhet li poluchit'sya tak, chto ispol'zovanie currval() i
nextval() privedet k zaciklirovaniyu s drugimi pol'zovatelyami?
Net. currval() vozvraschaet tekuschee znachenie, naznachennoe vashem
backend'om, a ne drugimi pol'zovatelyami.
4.15.4) Pochemu chisla iz moej posledovatel'nosti ne ispol'zuyutsya snova
pri otmene tranzakcii? Pochemu sozdayutsya razryvy pri numeracii v kolonke,
gde ya ispol'zuyu posledovatel'nost'/SERIAL?
Dlya realizacii konkuretnosti, znacheniya posledovatel'nostej, pri
neobhodimosti vydayutsya vo vremya zapuska tranzakcij i ne
blokiruyutsya do polnogo vypolneniya tranzakcij. `Eto mozhet vyzyvat'
razryvy v numeracii pri otmene tranzakcij.
4.16) CHto takoe OID? CHto takoe TID?
Polya OID sluzhat unikal'nymi idetifikatorami zapisej v PostgreSQL.
Kazhdaya zapis', kotoraya sozdaiotsya v PostgreSQL poluchaet
unikal'nyj OID. Vse znacheniya OID generiruemye vo vremya initdb
imeyut znacheniya men'she 16384 (iz include/access/transam.h). Vse
sozdannye pol'zovatelem OID imeyut bOl'shie znachenie. Po umolchaniyu,
vse `eti OID yavlyayutsya unikal'nymi ne tol'ko vnutri kakoj-libo
tablicy ili bazy dannyh, no i vnutri vsej SUBD PostgreSQL.
PostgreSQL ispol'zuet OID v svoih vnutrennih sistemnyh tablicah dlya
svyazi zapisej i tablic. Znacheniya OID mogut byt' ispol'zovany dlya
identifikacii zadannyh pol'zovatelem zapisej, a takzhe ispol'zovat'sya
pri svyazyvaniyah. Rekomenduetsya ispol'zovat' tip kolonki OID dlya
hraneniya znachenij OID Vy mozhete sozdat' indeks na pole OID dlya
bolee bystrogo dostupa.
Znacheniya OID naznachayutsya dlya vseh novyh zapisej iz central'noj
oblasti, kotorye ispol'zuyutsya vsemi vsemi bazami dannyh. Esli vy
hotite izmenit' OID na kakoe-libo drugoe znachenie ili esli vy hotite
sozdat' kopiyu tablicy s takimizhe OID, to `eto mozhno sdelat' tak:
2002-04-12 17:17:10 +08:00
CREATE TABLE new_table(old_oid oid, mycol int);
SELECT old_oid, mycol INTO new FROM old;
COPY new TO '/tmp/pgtable';
DELETE FROM new;
COPY new WITH OIDS FROM '/tmp/pgtable';
OID hranitsya kak 4-h bajtnoe celoe i ne mozhet prevyshat' znachenie v
4 milliarda. Odnako, esche nikto ne soobschil o tom, chto takoe
proizoshlo, no my planiruem do togo kak `eto sluchit'sya izbavitsya ot
`etogo ogranicheniya.
2002-04-12 17:17:10 +08:00
TID ispol'zuetsya dlya identifikacii special'nyh fizicheskih zapisej s
blochnymi i offset znacheniyami. TID izmenyaetsya posle togo kak
zapisi byli izmeneny ili peregruzheny.
2002-04-12 17:17:10 +08:00
TID ispol'zuetsya indeksnymi zapisyami v kachestve ukazatelya na
fizicheskie zapisi.
2002-04-12 17:17:10 +08:00
4.17) CHto oznachayut nekotorye terminy ispol'zuemye v PostgreSQL?
2002-04-12 17:17:10 +08:00
Nekotoryj ishodnyj kod i staraya dokumentaciya ispol'zuyut
obscheupotrebitel'nye terminy. Vot nekotorye iz nih:
2002-04-12 17:17:10 +08:00
* table, relation, class
* row, record, tuple
* column, field, attribute
* retrieve, select
* replace, update
* append, insert
* OID, serial value
* portal, cursor
* range variable, table name, table alias
Spisok obschih terminov po bazam dannyh mozhno najti na
http://hea-www.harvard.edu/MST/simul/software/docs/pkgs/pgsql/glossary
/glossary.html
2002-04-12 17:17:10 +08:00
4.18) Pochemu ya poluchayu oshibku "ERROR: Memory exhausted in
AllocSetAlloc()"?
2002-04-12 17:17:10 +08:00
Predpolozhitel'no u vas zakonchilas' virtual'naya pamyat' ili chto
vashe yadro imeet malen'kij limit na opredelennye resursy. Popytajtes'
pered zapuskom postmaster vypolnit' sleduyuschie komandy:
2002-04-12 17:17:10 +08:00
ulimit -d 262144
limit datasize 256m
V zavisimosti ot komandnogo interpretatora shell, tol'ko odna iz
dannyh komand vypolnitsya uspeshno, no ona pozvolit vam ustanovit'
bol'shij segment dannyh processa i vozmozhno reshit problemu. `Eta
komanda izmenyaet parametry tekuschego processa i vseh ego potomkov,
sozdannyh posle eio zapuska. Esli u vas voznikla problema s SQL
klientom, potomu chto backend vozvraschaet slishkom bol'shoj ob"em
dannyh, popytajtes' vypolnit' `etu komandu pered zapuskom klienta.
4.19) Kak mne uznat', kakaya versiya PostgreSQL zapuschena?
2002-04-12 17:17:10 +08:00
Iz psql, naberite SELECT version();
2002-04-12 17:17:10 +08:00
4.20) Pochemu pri rabote s moim bol'shim ob"ektom ya poluchayu oshibku
"invalid large obj descriptor"?
2002-04-12 17:17:10 +08:00
Vam nuzhno pri ispol'zovanii bol'shogo ob"ekta pomestit' v nachale
BEGIN WORK i v konce COMMIT, a vnutri poluchivshegosya bloka lo_open
... lo_close.
V nastoyaschij moment PostgreSQL trebuet, chtoby pri zakrytii
bol'shogo ob"ekta proishodilo vypolnenie tranzakcii. Takim obrazom,
pervaya zhe popytka sdelat' chto-libo s bol'shim ob"ektom, ne
soblyudaya dannogo pravila privedet k soobscheniyu invalid large obj
descriptor, tak kak kod vypolnyayuschij rabotu nad bol'shim ob"ektom
(po krajnej mere v nastoyaschij moment) budet generirovat' soobschenie
ob oshibke esli vy ne ispol'zuete tranzakciyu.
Esli vy ispol'zuete takoj interfejs klienta kak ODBC, vam vozmozhno
ponadobitsya ustanovit' auto-commit off.
4.21) Kak mne sozdat' kolonku kotoraya po umolchaniyu budet soderzhat'
tekuschee vremya?
2002-04-12 17:17:10 +08:00
Ispol'zujte CURRENT_TIMESTAMP:
2002-04-12 17:17:10 +08:00
CREATE TABLE test (x int, modtime timestamp DEFAULT CURRENT_TIMESTAMP );
4.22) Pochemu moi podzaprosy, ispol'zuyuschie IN tak medlenno rabotaeyut?
V nastoyaschij moment, my svyazyvaem pozaprosy dlya vneshnih zaprosov
cherez posledovatel'nyj perebor rezul'tata podzaprosa dlya kazhdoj
zapisi vneshnego zaprosa. Esli podzapros vozvraschaet tol'ko neskol'ko
zapisej i vneshnij zapros vozvraschaet mnogo zapisej, IN rabotaet
naibolee bystro. CHtoby uvelichit' skorost' v drugih zaprosah,
zamenite IN na EXISTS:
SELECT *
2002-04-12 17:17:10 +08:00
FROM tab
WHERE col IN (SELECT subcol FROM subtab);
2002-04-12 17:17:10 +08:00
na:
SELECT *
2002-04-12 17:17:10 +08:00
FROM tab
WHERE EXISTS (SELECT subcol FROM subtab WHERE subcol = col);
2002-04-12 17:17:10 +08:00
CHtoby takaya konstrukciya rabotala bystro, kolonka subcol dolzhna
2003-02-14 22:05:00 +08:00
byt' proindeksirovana. `Eta problema proizvoditel'nosti budet
ustranena v versii 7.4.
2002-04-12 17:17:10 +08:00
4.23) Kak mne vypolnit' vneshnee svyazyvanie?
2002-04-12 17:17:10 +08:00
PostgreSQL podderzhivaet vneshnee svyazyvanie, ispol'zuya standartnyj
sintaksis SQL. Vot dva primera:
2002-04-12 17:17:10 +08:00
SELECT *
FROM t1 LEFT OUTER JOIN t2 ON (t1.col = t2.col);
ili
2002-04-12 17:17:10 +08:00
SELECT *
FROM t1 LEFT OUTER JOIN t2 USING (col);
`Eto identichnye zaprosy svyazyvaniya t1.col i t2.col, takzhe
vozvraschayut lyubye nesvyazannye zapisi v t1 (kotorye ne sovpadayut s
t2). RIGHT svyazyvanie dolzhno dobavit' nesvyazannye zapisi t2. FULL
svyazyvanie dolzhno vozvratit' sovpavshie zapisi plyus vse
nesvyazannye zapisi iz t1 i t2. Slovo OUTER yavlyaetsya
neobyazatel'nym i naznachaetsya v LEFT, RIGHT i FULL svyazyvaniyah.
Obychnye svyazyvaniya nazyvayutsya INNER svyazyvaniya.
V predyduschih versiyah, vneshnie svyazyvaniya mogli byt' `emulirovany
ispol'zuya UNION i NOT IN. Naprimer, kogda proishodit svyazyvanie tab1
i tab2, sleduyuschij zapros vypolnyaet vneshnee svyazyvanie dvuh
tablic:
2002-04-12 17:17:10 +08:00
SELECT tab1.col1, tab2.col2
FROM tab1, tab2
WHERE tab1.col1 = tab2.col1
UNION ALL
SELECT tab1.col1, NULL
FROM tab1
WHERE tab1.col1 NOT IN (SELECT tab2.col1 FROM tab2)
ORDER BY col1
4.24) Kak vypolnyat' zaprosy, ispol'zuyuschie neskol'ko baz dannyh?
Ne suschestvuet sposoba sozdat' zapros k bazam dannyh otlichnym ot
tekuschej. Poskol'ku PostgreSQL zagruzhaet sistemnye katalogi
specifichnye dlya bazy dannyh, neponyatno dazhe, kak dolzhen sebya
vesti takoj mezhbazovyj zapros.
contrib/dblink pozvolyaet zaprosy mezhdu bazami, ispol'zuya vyzovy
funkcij. Razumeetsya, klient mozhet odnovremenno ustanavlivat'
soedieneniya s razlichnymi bazami dannyh i takih obrazom ob"edinyat'
informaciyu iz nih.
4.25) Kak mne vernut' iz funkcii neskol'ko zapisej?
V versii 7.3, vy mozhete legko vernut' neskol'ko zapisej ili kolonok
iz kakoj-libo funkcii,
http://techdocs.postgresql.org/guides/SetReturningFunctions
.
4.26) Pochemu ya ne mogu nadezhno sozdavat'/udalyat' vremennye tablicy v
funkciyah PL/PgSQL?
PL/PgSQL k`eshiruet soderzhimoe funkcii i odin iz negativnyh `effektov
`etogo sostoit v tom, chto esli funkciya PL/PgSQL obraschaetsya k
vremennoj tablice i `eta tablica pozdnee udalyaetsya i peresozdaetsya,
a funkciya zatem vyzyvaetsya snova, to ee vyzov privedet k oshibke,
potomu chto sk`eshirovannoe soderzhimoe funkcii soderzhit ukazatel' na
staruyu vremennuyu tablicu. CHtoby reshit' `etu problemu, ispol'zujte
EXECUTE dlya dostupa k vremennym tablicam v PL/PgSQL. Ispol'zovanie
`etogo operatora zastavit zapros peregenerirovat'sya kazhdyj raz.
4.27) Kakie opcii replikacii suschestvuyut?
Est' neskol'ko opcij dlya replikacii tipa master/slave. Oni dopuskayut
ispol'zovanie tol'ko master servera dlya vneseniya izmenenij v bazu
dannyh, a slave servery prosto pozvolyayut chitat' dannye iz bazy. Ob
`etom chitajte zdes':
http://gborg.PostgreSQL.org/genpage?replication_research. O replikacii
s neskol'kimi master serverami chitajte zdes':
http://gborg.PostgreSQL.org/project/pgreplication/projdisplay.php.
4.28) Kakie opcii shifrovaniya suschestvuyut?
* contrib/pgcrypto soderzhit mnogo funkcij shifrovaniya dlya
ispol'zovaniya v SQL zaprosah.
* Est' tol'ko odin sposob shifrovaniya dannyh, peredavaemyh ot
klienta k serveru, cherez ispol'zovanie hostssl v pg_hba.conf.
* Paroli pol'zovatelej k baze dannyh avtomaticheski shifruyutsya,
pri sohranenii v versii 7.3. V predyduschih versiyah, vy dolzhny
razreshit' opciyu PASSWORD_ENCRYPTION v postgresql.conf.
* Server mozhno zapustit', ispol'zuya shifrovannuyu fajlovuyu
sistemu.
2002-04-12 17:17:10 +08:00
_________________________________________________________________
Rasshireniya PostgreSQL
2002-04-12 17:17:10 +08:00
5.1) YA napisal funkciyu opredelyaemuyu pol'zovatelem. Kogda ya zapuskayu
ee v psql, pochemu ya poluchayu dump core?
2002-04-12 17:17:10 +08:00
Problema mozhet zaklyuchat'sya v neskol'kih veschah. Popytajtes'
sperva protestirovat' vashu funkciyu v otdel'noj samostoyatel'noj
programme.
2002-04-12 17:17:10 +08:00
5.2) Kak ya mogu vnesti nekotorye klassnye novye tipy i funkcii v
2002-04-12 17:17:10 +08:00
PostgreSQL?
Otprav'te vashi rasshireniya v spisok rassylki pgsql-hackers i oni po
vozmozhnosti budut pomescheny v podkatalog contrib/.
2002-04-12 17:17:10 +08:00
5.3) Kak mne napisat' C funkciyu, vozvraschayuschuyu zapis'?
2002-04-12 17:17:10 +08:00
V versiyah PostgreSQL, nachinaya s 7.3, funkcii, vozvraschayuschie
tablicy polnost'yu podderzhivayutsya v C, PL/PgSQL i SQL. Podrobnosti
smotrite v Rukovodstve Programmista. Primer vozvraschayuschej tablicu
funkcii, napisannoj na C, mozhno najti v contrib/tablefunc.
2002-04-12 17:17:10 +08:00
5.4) YA izmenil ishodnyj fajl. Pochemu posle perekompilyacii ya ne vizhu
izmenenij?
2002-04-12 17:17:10 +08:00
Fajly Makefile ne imeyut pravil'nyh zavisimostej dlya include fajlov.
Vy dolzhny vypolnit' make clean i zatem make. Esli vy ispol'zuete GCC
vy mozhete ispol'zovat' opciyu --enable-depend v configure chtoby
poruchit' kompilyatoru avtomaticheski otslezhivat' zavisimosti.