5.1) Kullan<EFBFBD>c<EFBFBD>-tan<EFBFBD>ml<EFBFBD> bir fonksiyon yazd<EFBFBD>m. psql'de <EFBFBD>al<EFBFBD><EFBFBD>t<EFBFBD>rd<EFBFBD><EFBFBD><EFBFBD>m zaman neden
core dump ediyor?
5.2) PostgreSQL'e nas<EFBFBD>l yeni veri tipleri/fonksiyonlar ekleyebilirim?
5.3) Bir tuple d<EFBFBD>nd<EFBFBD>rmek i<EFBFBD>in bir C fonksiyonunu nas<EFBFBD>l yazar<EFBFBD>m?
5.4) Bir kaynak dosyas<EFBFBD>nda de<EFBFBD>isiklik yapt<EFBFBD>m. Yeniden derlememe ra<EFBFBD>men
PostgreSQL, yeni-nesil VTYS arast<EFBFBD>rma prototipi olan POSTGRES veritaban<EFBFBD>
y<EFBFBD>netim sisteminin geli<EFBFBD>tirilmesidir. POSTGRES' in zengin veri
tiplerini ve g<EFBFBD><EFBFBD>l<EFBFBD> veri modelini tutarken, SQL'in geli<EFBFBD>tirilmis alt k<EFBFBD>mesi
olan PostQuel dilini kullan<EFBFBD>r. PostgreSQL <EFBFBD>cretsizdir ve kaynak kodu a<EFBFBD><EFBFBD>k da<EFBFBD><EFBFBD>t<EFBFBD>l<EFBFBD>r.
PostgreSQL, PostgreSQL gelistirme listesine <EFBFBD>ye olan bir <EFBFBD>nternet gelistirici
tak<EFBFBD>m<EFBFBD> taraf<EFBFBD>ndan geli<EFBFBD>tirilir. <EFBFBD>u andaki koordinat<EFBFBD>r, Marc G. Fournier
(scrappy@PostgreSQL.org). (Bu tak<EFBFBD>ma nas<EFBFBD>l kat<EFBFBD>lacag<EFBFBD>n<EFBFBD>z<EFBFBD><EFBFBD>grenmek i<EFBFBD>in
1.6 numaral<EFBFBD> maddeyi okuyunuz.) Bu tak<EFBFBD>m, t<EFBFBD>m PostgreSQL geli<EFBFBD>iminden sorumludur.
PostgreSQL 1.01 s<EFBFBD>r<EFBFBD>m<EFBFBD>n<EFBFBD>n yazarlar<EFBFBD> Andrew Yu ve Jolly Chen idi. Bunlar<EFBFBD>n d<EFBFBD>s<EFBFBD>nda bir ka<EFBFBD> kisi de uyarlama,
hata ay<EFBFBD>klama ve kodun gelistirilmesi i<EFBFBD>in <EFBFBD>al<EFBFBD>sm<EFBFBD>st<EFBFBD>. PostgreSQL'in t<EFBFBD>redigi orijinal Postgres kodu,
lisans, lisans<EFBFBD>st<EFBFBD> ve akademisyenler tarafindan, Professor Michael Stonebraker ) University of
PostgreSQL, di<EFBFBD>er ticari ve a<EFBFBD><EFBFBD>k kaynak kodlu veritabanlar<EFBFBD>yla yak<EFBFBD>n ba<EFBFBD>ar<EFBFBD>m<EFBFBD> sa<EFBFBD>lar.
Baz<EFBFBD> a<EFBFBD><EFBFBD>lardan daha h<EFBFBD>zl<EFBFBD>d<EFBFBD>r, di<EFBFBD>er a<EFBFBD><EFBFBD>lardan da yava<EFBFBD>t<EFBFBD>r. MySQL ya da daha zay<EFBFBD>f
veritabanlar<EFBFBD> ile kar<EFBFBD><EFBFBD>la<EFBFBD>t<EFBFBD>r<EFBFBD>ld<EFBFBD><EFBFBD><EFBFBD>nda,insert/update islemlerinde, transaction bazl<EFBFBD>
<EFBFBD>al<EFBFBD>st<EFBFBD><EFBFBD><EFBFBD>m<EFBFBD>z i<EFBFBD>in daha yava<EFBFBD><EFBFBD>z. MySQL, yukar<EFBFBD>daki "<EFBFBD>zellikler" k<EFBFBD>sm<EFBFBD>nda belirtilenlerden
hi<EFBFBD> birine sahip de<EFBFBD>ildir. Biz, ba<EFBFBD>ar<EFBFBD>m<EFBFBD>m<EFBFBD>z<EFBFBD> her s<EFBFBD>r<EFBFBD>mde artt<EFBFBD>rsak da, esneklik ve
geli<EFBFBD>mi<EFBFBD><EFBFBD>zellikler i<EFBFBD>in yap<EFBFBD>lanm<EFBFBD>s durumday<EFBFBD>z . PostgreSQL'i MySQL ile kar<EFBFBD><EFBFBD>la<EFBFBD>t<EFBFBD>ran
<EFBFBD>u web sitesine bakabilirsiniz: http://openacs.org/why-not-mysql.html
<EFBFBD>ok iyi test edilmis, dengeli <EFBFBD>al<EFBFBD>san minimum say<EFBFBD>da hata i<EFBFBD>eren kod sunmaya <EFBFBD>al<EFBFBD>s<EFBFBD>yoruz.
Her bir s<EFBFBD>r<EFBFBD>m en az 1 ayl<EFBFBD>k beta testlerinden ge<EFBFBD>irilmektedir. S<EFBFBD>r<EFBFBD>m ge<EFBFBD>mi<EFBFBD>ine bakarsan<EFBFBD>z,
<EFBFBD>retime haz<EFBFBD>r, dengeli ve kararl<EFBFBD> kodlar sundugumuzu g<EFBFBD>rebilirsiniz. Bu alanda, diger
E-posta listemiz, olusan herhangi bir sorunu <EFBFBD><EFBFBD>zebilecek b<EFBFBD>y<EFBFBD>k say<EFBFBD>da kullan<EFBFBD>c<EFBFBD>
ve gelistirici grubunu i<EFBFBD>erir. Sorununuz i<EFBFBD>in, en az bir ticari veritaban<EFBFBD> kadar
rahat <EFBFBD><EFBFBD>z<EFBFBD>m bulabilirsiniz. Gelistiricilere, kullan<EFBFBD>c<EFBFBD> grubuna, belgelere ve
kaynak koda direk olarak erisebilme, PostgreSQL destegini, diger DBMSlere g<EFBFBD>re daha
<EFBFBD>nemli k<EFBFBD>lar. Gereksinimi olanlara, ticari destek verilebilir. (Destek i<EFBFBD>in 1.6 b<EFBFBD>l<EFBFBD>m<EFBFBD>ne bak<EFBFBD>n<EFBFBD>z.)
Fiyat
Ticari ve ticari olmayan t<EFBFBD>m kullan<EFBFBD>mlar<EFBFBD>n<EFBFBD>z i<EFBFBD>in PostgreSQL <EFBFBD>cretsizdir. Kodumuzu, yukar<EFBFBD>da belirtilen
1.15) PostgreSQL'e maddi a<EFBFBD><EFBFBD>dan nas<EFBFBD>l destek olabilirim?
PostgreSQL, 1996 y<EFBFBD>l<EFBFBD>ndan beri 1.s<EFBFBD>n<EFBFBD>f altyap<EFBFBD>ya ashiptir. Bunun i<EFBFBD>in, y<EFBFBD>llar boyu <EFBFBD>al<EFBFBD>s<EFBFBD>p bu altyap<EFBFBD>y<EFBFBD>
olusturup y<EFBFBD>neten Marc Fournier'e tesekk<EFBFBD>rler.
Bir a<EFBFBD><EFBFBD>k kaynak kodlu proje i<EFBFBD>in, kaliteli altyap<EFBFBD><EFBFBD>ok <EFBFBD>nemlidir. Bu altyap<EFBFBD>, projenin
kesilmesini <EFBFBD>nler ve projenin ilerlemesini h<EFBFBD>zland<EFBFBD>r<EFBFBD>r.
Tabii ki bu altyap<EFBFBD> ucuz degildir. <EFBFBD>slerin y<EFBFBD>r<EFBFBD>mesi i<EFBFBD>in <EFBFBD>e<EFBFBD>itli y<EFBFBD>l<EFBFBD>k ve anl<EFBFBD>k
harcamalar<EFBFBD>m<EFBFBD>z olmaktad<EFBFBD>r. Eger siz ya da sirketinizin bu <EFBFBD>abam<EFBFBD>za bag<EFBFBD>sta
g<EFBFBD>zlemler ve beklenmeyen bir durumda program<EFBFBD> durdurur.
Postmaster ve postgres <EFBFBD>e<EFBFBD>itli hata ay<EFBFBD>klama se<EFBFBD>eneklerine sahiptir. <EFBFBD>ncelikle,
postmaster'i ba<EFBFBD>latt<EFBFBD><EFBFBD><EFBFBD>n<EFBFBD>zda, standart <EFBFBD><EFBFBD>kt<EFBFBD>y<EFBFBD> ve hatalar<EFBFBD> bir log dosyas<EFBFBD>na
y<EFBFBD>nlendirdi<EFBFBD>inize emin olun:
cd /usr/local/pgsql
./bin/postmaster >server.log 2>&1 &
Bu i<EFBFBD>lem PostgreSQL ana dizinine server.log dosyas<EFBFBD> yerle<EFBFBD>tirecektir. Bu dosya sunucunun
ya<EFBFBD>ad<EFBFBD><EFBFBD><EFBFBD> sorunlar ya da hatalar hakk<EFBFBD>nda yararl<EFBFBD> bilgiler i<EFBFBD>erir. -d se<EFBFBD>ene<EFBFBD>i, hata
ay<EFBFBD>klama seviyesini belirten bir rakam ile kullan<EFBFBD>l<EFBFBD>r. Y<EFBFBD>ksek hata ay<EFBFBD>klama
direk olarak yazabilirsiniz. Bu sadece hata ay<EFBFBD>klama amac<EFBFBD>yla <EFBFBD>nerilir. Burada, noktal<EFBFBD> virg<EFBFBD>l<EFBFBD>n de<EFBFBD>il de
yeni bir sat<EFBFBD>r<EFBFBD>n sorguyu sonland<EFBFBD>rd<EFBFBD><EFBFBD><EFBFBD>n<EFBFBD> unutmay<EFBFBD>n<EFBFBD>z. E<EFBFBD>er hata ay<EFBFBD>klama sembolleri ile derlediyseniz,
ne oldu<EFBFBD>unu g<EFBFBD>rmek i<EFBFBD>in bir hata ay<EFBFBD>klay<EFBFBD>c<EFBFBD> kullanabilirsiniz. backend postmasterdan ba<EFBFBD>lat<EFBFBD>lmad<EFBFBD><EFBFBD><EFBFBD>ndan,
e<EFBFBD>de<EFBFBD>er bir ortamda <EFBFBD>al<EFBFBD><EFBFBD>mamaktad<EFBFBD>r ve locking/backend etkile<EFBFBD>im sorunlar<EFBFBD> artabilir.
E<EFBFBD>er postmaster <EFBFBD>al<EFBFBD><EFBFBD><EFBFBD>yorsa, bir pencerede psql'i <EFBFBD>al<EFBFBD><EFBFBD>t<EFBFBD>r<EFBFBD>n ve psql taraf<EFBFBD>ndan kullan<EFBFBD>lan postgres s<EFBFBD>recinin s<EFBFBD>re<EFBFBD>
numaras<EFBFBD>n<EFBFBD> (PID) bulun. Postgres s<EFBFBD>reci ile ili<EFBFBD>kilendirmek i<EFBFBD>in bir hata ay<EFBFBD>klar<EFBFBD>c<EFBFBD> kullan<EFBFBD>n. Sorgular<EFBFBD> psql
arac<EFBFBD>l<EFBFBD><EFBFBD><EFBFBD> ile <EFBFBD>al<EFBFBD><EFBFBD>t<EFBFBD>rabilirsiniz. E<EFBFBD>er postgres ba<EFBFBD>lang<EFBFBD>c<EFBFBD>nda hata ay<EFBFBD>klamak istiyorsan<EFBFBD>z, PGOPTIONS="-W n"
se<EFBFBD>ene<EFBFBD>ini ayarlayabilir ve psql'i ba<EFBFBD>latabilirsiniz. Bu i<EFBFBD>lem, ba<EFBFBD>lang<EFBFBD>c<EFBFBD>n n saniye kadar gecikmesini
sa<EFBFBD>layacakt<EFBFBD>r; b<EFBFBD>ylece hata ay<EFBFBD>klay<EFBFBD>c<EFBFBD>y<EFBFBD> s<EFBFBD>rece ili<EFBFBD>kilendirdikten sonra ba<EFBFBD>lang<EFBFBD><EFBFBD> s<EFBFBD>recinin devam etmesini
sa<EFBFBD>layabilirsiniz.
postgres program<EFBFBD> hata ay<EFBFBD>klama ve ba<EFBFBD>ar<EFBFBD>m <EFBFBD>l<EFBFBD><EFBFBD>mleri i<EFBFBD>in -s, -A ve -t se<EFBFBD>eneklerine sahiptir.
3.8) Baglanmaya <EFBFBD>al<EFBFBD>s<EFBFBD>ken, neden "Sorry, too many clients" hatas<EFBFBD>n<EFBFBD> al<EFBFBD>yorum?
Postmaster'in e<EFBFBD>zamanl<EFBFBD> olarak ba<EFBFBD>latabilece<EFBFBD>i backend s<EFBFBD>re<EFBFBD>leri s<EFBFBD>n<EFBFBD>rlar<EFBFBD>n<EFBFBD>
artt<EFBFBD>rman<EFBFBD>z gerekmektedir.
<EFBFBD>n tan<EFBFBD>ml<EFBFBD> de<EFBFBD>er 32 s<EFBFBD>re<EFBFBD>tir. Bunu, postmaster'i uygun -N de<EFBFBD>eri ile ya da
postgresql.conf dosyas<EFBFBD>n<EFBFBD> d<EFBFBD>zenleyerek yeniden ba<EFBFBD>latmakla artt<EFBFBD>rabilirsiniz.
E<EFBFBD>er -N de<EFBFBD>erini 32'den b<EFBFBD>y<EFBFBD>k yapacaksan<EFBFBD>z, ayn<EFBFBD> zamanda -B de<EFBFBD>erini de de<EFBFBD>i<EFBFBD>tirmeniz
gerekti<EFBFBD>ini unutmay<EFBFBD>n. -B -N'nin en az 2 kat<EFBFBD> kadar olmal<EFBFBD>d<EFBFBD>r; daha iyi ba<EFBFBD>ar<EFBFBD>m i<EFBFBD>in
bu say<EFBFBD>y<EFBFBD> daha da artt<EFBFBD>rmal<EFBFBD>s<EFBFBD>n<EFBFBD>z. Y<EFBFBD>ksek say<EFBFBD>daki backend s<EFBFBD>re<EFBFBD>leri i<EFBFBD>in, <EFBFBD>e<EFBFBD>itli <EFBFBD>ekirdek yap<EFBFBD>land<EFBFBD>rma
a<EFBFBD><EFBFBD>labilecek dosyalar<EFBFBD>n maksimum say<EFBFBD>s<EFBFBD> olan NFILE ve NINODE de<EFBFBD>erlerini kar<EFBFBD><EFBFBD>t<EFBFBD>rmakt<EFBFBD>r. Bunun nedeni, PostgreSQL'in
izin verilen backend s<EFBFBD>re<EFBFBD>lerinin say<EFBFBD>s<EFBFBD><EFBFBD>zerinde bir s<EFBFBD>n<EFBFBD>r<EFBFBD> olmas<EFBFBD>d<EFBFBD>r. B<EFBFBD>ylelikle sistem kaynaklar<EFBFBD>n<EFBFBD>n d<EFBFBD><EFBFBD><EFBFBD>na
<EFBFBD><EFBFBD>k<EFBFBD>lmayacakt<EFBFBD>r.
PostgreSQL'in 6.5 s<EFBFBD>r<EFBFBD>m<EFBFBD>ne kadar, en fazla backend say<EFBFBD>s<EFBFBD> 64 idi ve bunu de<EFBFBD>i<EFBFBD>tirmek i<EFBFBD>in
include/storage/sinvaladt.h dosyas<EFBFBD> i<EFBFBD>indeki MaxBAckendid sabitini de<EFBFBD>i<EFBFBD>tirdek sonra
yaz<EFBFBD>l<EFBFBD>m<EFBFBD> yeniden derlemek gerekiyordu.
3.9) pgsql_tmp dizinin i<EFBFBD>indeki dosyalar nelerdir?
bir s<EFBFBD>ralama ORDER BY ile yapilacaksa ve s<EFBFBD>ralama backend'in -s parametresinin izin
verdiginden daha fazla alana gereksinim duyuyorsa, ekstra veriyi tutmak i<EFBFBD>in ge<EFBFBD>ici
dosyalar yarat<EFBFBD>l<EFBFBD>r.
Ge<EFBFBD>ici dosyalar, eger s<EFBFBD>ralama s<EFBFBD>ras<EFBFBD>nda backend g<EFBFBD><EFBFBD>mezse otomatik olarak silinecektir.
Eger <EFBFBD>al<EFBFBD>san durumda bir backendiniz yoksa, pg_tempNNN.NN dosyalar<EFBFBD>n<EFBFBD> silmeniz g<EFBFBD>venlidir..
3.10) PostgreSQL s<EFBFBD>r<EFBFBD>mlerini y<EFBFBD>kselmek i<EFBFBD>in neden bir dump/reload i<EFBFBD>lemi ger<EFBFBD>ekle<EFBFBD>tirmek zorunday<EFBFBD>m?
PostgreSQL tak<EFBFBD>m<EFBFBD> ara s<EFBFBD>r<EFBFBD>mlerde sadece k<EFBFBD><EFBFBD><EFBFBD>k de<EFBFBD>i<EFBFBD>iklikler yapmaktad<EFBFBD>r; bu y<EFBFBD>zden 7.2
s<EFBFBD>r<EFBFBD>m<EFBFBD>nden 7.2.1'e y<EFBFBD>kseltmek dump/restore i<EFBFBD>lemi gerekmemektedir. Ancak, esas s<EFBFBD>r<EFBFBD>mlerde
(<EFBFBD>rnek: 7.2'den 7.3'e) <EFBFBD>o<EFBFBD>unlukla sistem tablolar<EFBFBD>n<EFBFBD>n ve veri dosyalar<EFBFBD>n<EFBFBD>n i<EFBFBD> yap<EFBFBD>s<EFBFBD>
de<EFBFBD>i<EFBFBD>tirilir. Bu de<EFBFBD>i<EFBFBD>iklikler <EFBFBD>o<EFBFBD>unlukla karma<EFBFBD><EFBFBD>kt<EFBFBD>r; dolay<EFBFBD>s<EFBFBD>yla veri dosyalar<EFBFBD>n<EFBFBD>n
geriye d<EFBFBD>n<EFBFBD>k uyumlulu<EFBFBD>u i<EFBFBD>lemlerini yapm<EFBFBD>yoruz. Dump i<EFBFBD>lemi, veriyi genel bi<EFBFBD>imde
alaca<EFBFBD><EFBFBD>ndan yeniden y<EFBFBD>kleme esnas<EFBFBD>nda veri, yeni i<EFBFBD> bi<EFBFBD>ime uygun <EFBFBD>ekilde
yerle<EFBFBD>tirilecektir.
Disk bi<EFBFBD>iminin de<EFBFBD>i<EFBFBD>medi<EFBFBD>i s<EFBFBD>r<EFBFBD>mlerde, pg_upgrade beti<EFBFBD>i g<EFBFBD>ncellemenin bir dump/restore
gerektirmeden yap<EFBFBD>lmas<EFBFBD>n<EFBFBD> sa<EFBFBD>layacakt<EFBFBD>r. pg_upgrade beti<EFBFBD>inin o s<EFBFBD>r<EFBFBD>m i<EFBFBD>in bulunup
<EFBFBD>lk birka<EFBFBD> sat<EFBFBD>r<EFBFBD> almak isteseniz bile, t<EFBFBD>m sorgu de<EFBFBD>erlendirilmek durumunda kal<EFBFBD>nabilir. ORDER BY i<EFBFBD>eren bir
sorgu d<EFBFBD><EFBFBD><EFBFBD>n<EFBFBD>n. E<EFBFBD>er ORDER BY i<EFBFBD>e e<EFBFBD>le<EFBFBD>en bir index varsa, PostgreSQL istenen ilk birka<EFBFBD> sat<EFBFBD>r<EFBFBD> i<EFBFBD>leyebilir, ya da
t<EFBFBD>m sorgu istenen sat<EFBFBD>rlar <EFBFBD>retilene kadar i<EFBFBD>lenebilir.
zamanda, psql'i -E se<EFBFBD>ene<EFBFBD>i ile ba<EFBFBD>lat<EFBFBD>p, verdi<EFBFBD>iniz komutlar<EFBFBD><EFBFBD>al<EFBFBD><EFBFBD>t<EFBFBD>rmak i<EFBFBD>in yapt<EFBFBD><EFBFBD><EFBFBD>
Bir sat<EFBFBD>r i<EFBFBD>in en fazla b<EFBFBD>y<EFBFBD>kl<EFBFBD>k nedir? 1.6 TB
Bir alan i<EFBFBD>in en fazla b<EFBFBD>y<EFBFBD>kl<EFBFBD>k nedir? 1 GB
Tabloda en fazla sat<EFBFBD>r say<EFBFBD>s<EFBFBD> ka<EFBFBD>t<EFBFBD>r? S<EFBFBD>n<EFBFBD>rs<EFBFBD>z
Bir tabloda olabilecek en fazla kolon say<EFBFBD>s<EFBFBD> ka<EFBFBD>t<EFBFBD>r? Kolon tiplerine ba<EFBFBD>l<EFBFBD> olarak 250-1600
Bir tabloda olabilecek en fazla index say<EFBFBD>s<EFBFBD> ka<EFBFBD>t<EFBFBD>r? s<EFBFBD>n<EFBFBD>rs<EFBFBD>z
Tabii ki bunlar aslinda s<EFBFBD>n<EFBFBD>rs<EFBFBD>z degildir. Burada belirtilen s<EFBFBD>n<EFBFBD>rlar, fiziksel
s<EFBFBD>n<EFBFBD>rlar<EFBFBD>n haricindeki s<EFBFBD>n<EFBFBD>rlard<EFBFBD>r. Bo<EFBFBD> disk alan<EFBFBD>, haf<EFBFBD>za/takas alan<EFBFBD> na ba<EFBFBD>l<EFBFBD>
s<EFBFBD>n<EFBFBD>rlamalar vard<EFBFBD>r. Ba<EFBFBD>ar<EFBFBD>m, s<EFBFBD>n<EFBFBD>r de<EFBFBD>erlere yaklast<EFBFBD>k<EFBFBD>a, ya da de<EFBFBD>erler cok b<EFBFBD>y<EFBFBD>k
oldu<EFBFBD>unda d<EFBFBD><EFBFBD>ebilir.
Bir tablo i<EFBFBD>in b<EFBFBD>y<EFBFBD>kl<EFBFBD>k s<EFBFBD>n<EFBFBD>r<EFBFBD> olan 16 TB, i<EFBFBD>letim sisteminin b<EFBFBD>y<EFBFBD>k dosya deste<EFBFBD>i olup
sistemi s<EFBFBD>n<EFBFBD>rlar<EFBFBD>nin bir <EFBFBD>nemi yoktur.
Tablo ve kolon say<EFBFBD>s<EFBFBD> b<EFBFBD>y<EFBFBD>kl<EFBFBD>kleri, <EFBFBD>n tan<EFBFBD>ml<EFBFBD> blok b<EFBFBD>y<EFBFBD>kl<EFBFBD><EFBFBD><EFBFBD> 32k ya <EFBFBD><EFBFBD>kar<EFBFBD>larak
artt<EFBFBD>r<EFBFBD>labilir.
4.6) Tipik bir metin dosyas<EFBFBD>ndaki veriyi saklamak i<EFBFBD>in ne kadar disk alan<EFBFBD> gereklidir?
Bir PostgreSQL veritaban<EFBFBD>, veriyi "flat" metin dosyas<EFBFBD>nda saklamak i<EFBFBD>in gereken
alan<EFBFBD>n 5 kat fazla disk alan<EFBFBD>na gereksinim duyabilir.
Her sat<EFBFBD>r<EFBFBD>nda bir tamsay<EFBFBD> ve metin (text) i<EFBFBD>eren, 100.000 sat<EFBFBD>rl<EFBFBD>k bir dosya d<EFBFBD><EFBFBD><EFBFBD>n<EFBFBD>n.
Her sat<EFBFBD>r<EFBFBD>n ortalama 20 byte oldu<EFBFBD>unu farzedelim. Metin dosyas<EFBFBD> 2.8 MB olacakt<EFBFBD>r. Bu veriyi
tutan PostgreSQL veritaban<EFBFBD> yakla<EFBFBD><EFBFBD>k 6.4 MB yer kaplayacakt<EFBFBD>r.
36 byte: Her bir sat<EFBFBD>r basl<EFBFBD>g<EFBFBD> (yaklasik)
+ 24 byte: Bir tamsay<EFBFBD> (int) alani ve bir metin (text) alan<EFBFBD>
+ 4 byte: Sayfada tuple a pointer
----------------------------------------
64 byte -> kay<EFBFBD>t bas<EFBFBD>na
PostgreSQL'de data page b<EFBFBD>y<EFBFBD>kl<EFBFBD><EFBFBD><EFBFBD> 8192 byte (8k)dir, dolay<EFBFBD>s<EFBFBD>yla:
8192 byte -> page bas<EFBFBD>na
------------------------- = Her bir veritabani page i ba<EFBFBD><EFBFBD>na 128 sat<EFBFBD>r (yakla<EFBFBD><EFBFBD>k)
Indexler her sorgu taraf<EFBFBD>ndan otomatik olarak kullan<EFBFBD>lmazlar. Indexler e<EFBFBD>er bir tablonun b<EFBFBD>y<EFBFBD>kl<EFBFBD><EFBFBD><EFBFBD> minimum bir
b<EFBFBD>y<EFBFBD>kl<EFBFBD>kten fazla ise ve sorgu tablodaki sat<EFBFBD>rlar<EFBFBD>n sadece k<EFBFBD><EFBFBD><EFBFBD>k bir y<EFBFBD>zdesini se<EFBFBD>iyorsa kullan<EFBFBD>l<EFBFBD>r. Bunun nedeni,
index eri<EFBFBD>iminin neden oldu<EFBFBD>u raslansal disk eri<EFBFBD>imi nin diskin ya da tablonun s<EFBFBD>ral<EFBFBD> okunmas<EFBFBD>ndan daha yavas
sat<EFBFBD>r oldu<EFBFBD>unu ve bilir ve indexin kullan<EFBFBD>l<EFBFBD>p kullan<EFBFBD>lmayaca<EFBFBD><EFBFBD>na daha iyi karar verir. Istatistikler, ayn<EFBFBD> zamanda en
uygun join s<EFBFBD>ras<EFBFBD>n<EFBFBD> ve y<EFBFBD>ntemini belirlemekte <EFBFBD>ok <EFBFBD>nemlidir. <EFBFBD>statistik toplanmas<EFBFBD>, tablo i<EFBFBD>erikleri de<EFBFBD>i<EFBFBD>tik<EFBFBD>e
periyodik olarak yap<EFBFBD>lmal<EFBFBD>d<EFBFBD>r.
Indexler normalde ORDER BY sorgular<EFBFBD> ya da join i<EFBFBD>lemlerini ger<EFBFBD>ekle<EFBFBD>tirmek i<EFBFBD>in kullan<EFBFBD>lmazlar. A<EFBFBD><EFBFBD>k bir s<EFBFBD>ralamay<EFBFBD>
takip eden s<EFBFBD>ral<EFBFBD> bir arama (sequential scan), b<EFBFBD>y<EFBFBD>k bir tabloda index aramas<EFBFBD> yapmaktan genelde daha h<EFBFBD>zl<EFBFBD>d<EFBFBD>r.
Ancak, ORDER BY ile birle<EFBFBD>mi<EFBFBD> LIMIT genellikle bir index kullanacakt<EFBFBD>r; <EFBFBD><EFBFBD>nk<EFBFBD> tablonun sadece belirli bir miktar<EFBFBD>
d<EFBFBD>nd<EFBFBD>r<EFBFBD>lecektir. Asl<EFBFBD>nda, MAX() ve MIN() fonksiyonlar<EFBFBD>n<EFBFBD>n index kullanmamalar<EFBFBD>ndan dolay<EFBFBD>, bu gibi de<EFBFBD>erleri ORDER BY
ve LIMIT kullanarak da almak olas<EFBFBD>d<EFBFBD>r:
E<EFBFBD>er optimizer'<EFBFBD>n s<EFBFBD>ral<EFBFBD> arama yapmas<EFBFBD>n<EFBFBD>n yanl<EFBFBD><EFBFBD> oldu<EFBFBD>una inan<EFBFBD>yorsan<EFBFBD>z, SET enable_seqscan TO 'off' kullan<EFBFBD>n ve
index kullanan aramalar<EFBFBD>n hala daha h<EFBFBD>zl<EFBFBD> olup olmad<EFBFBD><EFBFBD><EFBFBD>n<EFBFBD> g<EFBFBD>r<EFBFBD>n.
LIKE ya da ~ gibi operat<EFBFBD>rler kullan<EFBFBD>yorsan<EFBFBD>z, index'ler sadece a<EFBFBD>a<EFBFBD><EFBFBD>daki ko<EFBFBD>ullarda kullan<EFBFBD>labilir:
* ILIKE ve ~* gibi b<EFBFBD>y<EFBFBD>k/k<EFBFBD><EFBFBD><EFBFBD>k harfe duyars<EFBFBD>z aramalar index'lerden yararlanmazlar. Onun yerine, b<EFBFBD>l<EFBFBD>m 4.12'de
R-tree index, uzaysal (spatial) verileri indexlemek i<EFBFBD>in kullan<EFBFBD>l<EFBFBD>r. Bir hash index, dizi aramalar<EFBFBD>nda (range search)
kullan<EFBFBD>lamaz. B-tree index dizi aramalar<EFBFBD>nda sadece tek boyutlu <EFBFBD>al<EFBFBD><EFBFBD>maktad<EFBFBD>r. R-tree, <EFBFBD>ok boyutlu veriyi destekler.
<EFBFBD>rne<EFBFBD>in, e<EFBFBD>er bir R-tree index point veri tipi <EFBFBD>zerinde in<EFBFBD>a edililebilirse, sistem "select all points within a
bounding rectangle" gibi sorgulara daha verimli yan<EFBFBD>tlar verecektir.
Bu belgeyi, Stonebraker'<EFBFBD>n "Readings in Database Systems" kitab<EFBFBD>nda bulabilirsiniz.
G<EFBFBD>m<EFBFBD>l<EFBFBD> R-tree indexleri poligon ve boxlar<EFBFBD> kullanabilir. Teorik olarak, R-tree indexlerin <EFBFBD>zelliklerini
geni<EFBFBD>letmek bir miktar <EFBFBD>aba gerektirir ve bunun nas<EFBFBD>l yap<EFBFBD>laca<EFBFBD><EFBFBD>na dair bir belgemiz hen<EFBFBD>z bulunmamaktad<EFBFBD>r.
~ operat<EFBFBD>r<EFBFBD> d<EFBFBD>zenli ifade e<EFBFBD>le<EFBFBD>mesi ve ~* b<EFBFBD>y<EFBFBD>k/k<EFBFBD><EFBFBD><EFBFBD>k harfe duyars<EFBFBD>z d<EFBFBD>zenli ifade e<EFBFBD>le<EFBFBD>mesi yapar.
B<EFBFBD>y<EFBFBD>k/k<EFBFBD><EFBFBD><EFBFBD>k harfe duyarl<EFBFBD> olan LIKE'in b<EFBFBD>y<EFBFBD>k/k<EFBFBD><EFBFBD><EFBFBD>k harfe duyars<EFBFBD>z olan bi<EFBFBD>ini ILIKE't<EFBFBD>r ve PostgreSQL
7.1 s<EFBFBD>r<EFBFBD>m<EFBFBD> ile birlikte gelmi<EFBFBD>tir.
B<EFBFBD>y<EFBFBD>k-k<EFBFBD><EFBFBD><EFBFBD>k harfe duyars<EFBFBD>z e<EFBFBD>itlik kar<EFBFBD><EFBFBD>la<EFBFBD>t<EFBFBD>rmalar<EFBFBD> a<EFBFBD>a<EFBFBD><EFBFBD>daki gibi ifade edilir:
SELECT *
FROM tab
WHERE lower(col) = 'abc'
Bu standart bir indeks yaratmayacakt<EFBFBD>r. Ancak e<EFBFBD>er fonksiyonel bir indeks yarat<EFBFBD>rsan<EFBFBD>z; o kullan<EFBFBD>lacakt<EFBFBD>r:
<EFBFBD><EFBFBD> adlar<EFBFBD> (internal name) sistem kataloglar<EFBFBD>n<EFBFBD> ve baz<EFBFBD> hata meajlar<EFBFBD>n<EFBFBD> incelerken g<EFBFBD>receksiniz.
<EFBFBD>lk d<EFBFBD>rt veri tipi "varlena" tipidir (yani, diskteki ilk 4 bayt uzunluktur; devam<EFBFBD> da veridir.) Dolay<EFBFBD>s<EFBFBD>yla,
B<EFBFBD>ylece, kullan<EFBFBD>lan ger<EFBFBD>ek alan, belirtilen alandan biraz daha b<EFBFBD>y<EFBFBD>kt<EFBFBD>r. Ancak, bu veri tipleri, s<EFBFBD>k<EFBFBD><EFBFBD>t<EFBFBD>r<EFBFBD>lmaya tabi
tutulabilir; dolay<EFBFBD>s<EFBFBD>yla disk alan<EFBFBD> beklenilenden k<EFBFBD>c<EFBFBD>k olabilir. VARCHAR(n) b<EFBFBD>y<EFBFBD>kl<EFBFBD><EFBFBD><EFBFBD> artabilen ama en b<EFBFBD>y<EFBFBD>k
uzunlu<EFBFBD>u s<EFBFBD>n<EFBFBD>rl<EFBFBD> oan verileri saklamak i<EFBFBD>in en uygun y<EFBFBD>ntemdir. TEXT, 1 GB b<EFBFBD>y<EFBFBD>kl<EFBFBD><EFBFBD>e kadar olan verileri tutmak i<EFBFBD>in
kullan<EFBFBD>l<EFBFBD>r.
CHAR(n), ayn<EFBFBD> uzunluktaki dizilerin saklanmas<EFBFBD> i<EFBFBD>in kullan<EFBFBD>m<EFBFBD>r. CHAR(n) belirtilen uzunlu<EFBFBD>a kadar bo<EFBFBD>luk ile
doldurur; ancak VARCHAR(n) sadece verilen karakterleri saklar.BYTEA binary veri saklamak i<EFBFBD>indir; ayr<EFBFBD>ca "NULL" bayt
i<EFBFBD>eren de<EFBFBD>erleri de saklar. Burada anlat<EFBFBD>lan <EFBFBD><EFBFBD> veri tipi de benzer ba<EFBFBD>ar<EFBFBD>m karakteristiklere sahiptir.
id <EFBFBD>NT4 NOT NULL DEFAULT nextval('person_id_seq'),
name TEXT
);
CREATE UNIQUE <EFBFBD>NDEX person_id_key ON person ( id );
Sequenceler hakk<EFBFBD>nda daha fazla bilgi i<EFBFBD>in create_sequence yard<EFBFBD>m sayfas<EFBFBD>na bakabilirsiniz. Her sat<EFBFBD>r<EFBFBD>n OID alan<EFBFBD>n<EFBFBD>
tekil bir say<EFBFBD> olarak alabilirsiniz. Ancak, veritaban<EFBFBD>n<EFBFBD>z<EFBFBD>n dump'<EFBFBD>n<EFBFBD> al<EFBFBD>p yeniden y<EFBFBD>klerseniz, OID de<EFBFBD>erlerini
koruyabilmek i<EFBFBD>in pg_dump'<EFBFBD>n -o parametresini ya da "COPY WITH OIDS" se<EFBFBD>ene<EFBFBD>ini kullanman<EFBFBD>z gerekecektir.
4.15.2) SERIAL giri<EFBFBD>inin degerini nas<EFBFBD>l alabilirim?
Bir yakla<EFBFBD><EFBFBD>m, sequence nesnesindeki SERIAL de<EFBFBD>erini, veriyi girmeden <EFBFBD>nce nextval() ile al<EFBFBD>p, ald<EFBFBD><EFBFBD><EFBFBD>n<EFBFBD>z de<EFBFBD>eri
kendinizin girmesidir. 4.15.1'deki <EFBFBD>rnek tabloyu kullanarak bir <EFBFBD>rnek verelim:
Di<EFBFBD>er sorgular i<EFBFBD>in new_id'de yeni de<EFBFBD>erin saklanmas<EFBFBD> gerekir. Otomatik olarak yarat<EFBFBD>lan SEQUENE nesnesinin ad<EFBFBD>,
Son olarak, <EFBFBD>n tan<EFBFBD>ml<EFBFBD> de<EFBFBD>eri bulmak i<EFBFBD>in INSERT ifadesinden d<EFBFBD>nen OID de<EFBFBD>erini kullanabilirsiniz; ancak bu
en az ta<EFBFBD><EFBFBD>nabilir <EFBFBD><EFBFBD>z<EFBFBD>m olacakt<EFBFBD>r. Perl'de, Edmund Mergl'in DBD:Pg m<EFBFBD>d<EFBFBD>l<EFBFBD> ile birlikte DBI kullanarak, OID de<EFBFBD>eri
$sth->execute() <EFBFBD>al<EFBFBD><EFBFBD>t<EFBFBD>r<EFBFBD>ld<EFBFBD>ktan sonra $sth->(pg_OID_status) ile al<EFBFBD>nabilir.
OIDler, tekil sat<EFBFBD>r numaralar<EFBFBD>na PostgreSQL'in yan<EFBFBD>t<EFBFBD>d<EFBFBD>r. PostgreSQL'de yarat<EFBFBD>lan her say<EFBFBD>, tekil bir OID al<EFBFBD>r.
yarat<EFBFBD>lan t<EFBFBD>m OID'ler bu say<EFBFBD>ya e<EFBFBD>it ya da bu say<EFBFBD>dan b<EFBFBD>y<EFBFBD>kt<EFBFBD>r. Varsay<EFBFBD>lan durumda, t<EFBFBD>m bu OIDler sadece bir tablo ya
da veritaban<EFBFBD>nda de<EFBFBD>il, t<EFBFBD>m PostgreSQL kurulumunda tekildir.
PostgreSQL OIDleri, tablolar aras<EFBFBD>nda sat<EFBFBD>rlar<EFBFBD> ili<EFBFBD>kilendirmek i<EFBFBD>in kendi i<EFBFBD> tablolar<EFBFBD>nda kullan<EFBFBD>r. Bu OIDler
belirli kullan<EFBFBD>c<EFBFBD> sat<EFBFBD>rlar<EFBFBD>n<EFBFBD> belirtmek i<EFBFBD>in kullanabilir ve join i<EFBFBD>lemlerinde kullan<EFBFBD>l<EFBFBD>r. OID de<EFBFBD>erlerini saklamak
i<EFBFBD>in OID kolon tipini kullanman<EFBFBD>z <EFBFBD>nerinir. Daha h<EFBFBD>zl<EFBFBD> bir eri<EFBFBD>im i<EFBFBD>in, OID alan<EFBFBD>nda bir index yaratabilirsiniz.
OID'ler yeni sat<EFBFBD>rlara, t<EFBFBD>m veritabanlar<EFBFBD> taraf<EFBFBD>nda kullan<EFBFBD>lan ortak bir alandan atan<EFBFBD>rlar. E<EFBFBD>er OID'i ba<EFBFBD>ka bir
de<EFBFBD>ere e<EFBFBD>itlemek isterseniz ya da tablonun bir kopyas<EFBFBD>n<EFBFBD> orijinal OIDler ile <EFBFBD><EFBFBD>karmak isterseniz, bu m<EFBFBD>mk<EFBFBD>nd<EFBFBD>r:
OIDler 4-bit tamsay<EFBFBD> olarak saklan<EFBFBD>rlar ve 4 milyarda overflow olacakt<EFBFBD>r. Kimse bu say<EFBFBD>ya ula<EFBFBD>t<EFBFBD><EFBFBD><EFBFBD>na dair bir bilgi
iletmedi ve bu s<EFBFBD>n<EFBFBD>r<EFBFBD> kimse bu s<EFBFBD>n<EFBFBD>ra ula<EFBFBD>madan kald<EFBFBD>raca<EFBFBD><EFBFBD>z.
TIDler, belirli fiziksel sat<EFBFBD>rlar block ve offset de<EFBFBD>erleri ile belirtmekte kullan<EFBFBD>l<EFBFBD>r. TIDler, sat<EFBFBD>rlar de<EFBFBD>i<EFBFBD>ti<EFBFBD>inde
ya da yeniden y<EFBFBD>klendi<EFBFBD>inde de<EFBFBD>i<EFBFBD>irler. Index girdileri taraf<EFBFBD>ndan fiziksel sat<EFBFBD>rlar<EFBFBD> g<EFBFBD>stermek i<EFBFBD>in kullan<EFBFBD>l<EFBFBD>rlar.
7.4 s<EFBFBD>r<EFBFBD>m<EFBFBD>nden <EFBFBD>nce, subqueryler. E<EFBFBD>er subquery sadece birka<EFBFBD> sat<EFBFBD>r ve outer query bol say<EFBFBD>da sat<EFBFBD>r d<EFBFBD>nd<EFBFBD>r<EFBFBD>yorsa, IN
en h<EFBFBD>zl<EFBFBD>s<EFBFBD>d<EFBFBD>r. Sorgular<EFBFBD> h<EFBFBD>zland<EFBFBD>rmak i<EFBFBD>in IN yerine EXISTS kullan<EFBFBD>n:
Bunun h<EFBFBD>zl<EFBFBD> olabilmesi i<EFBFBD>in, subcol'un indekslenmi<EFBFBD> bir kolon olmas<EFBFBD> gerekmektedir.
7.4 s<EFBFBD>r<EFBFBD>m<EFBFBD> ve sonras<EFBFBD>nda, IN asl<EFBFBD>nda normal sorgularla ayn<EFBFBD> karma<EFBFBD><EFBFBD>k join tekniklerini kullan<EFBFBD>r ve EXISTS'e tercih
Bu <EFBFBD>zde<EFBFBD> sorgular t1.col ' i t2.col'ye join ederler ve ayn<EFBFBD> zamanda t1'deki unjoined sat<EFBFBD>rlar<EFBFBD>
(t2'de e<EFBFBD>lenmenis olanlarla) d<EFBFBD>nd<EFBFBD>r<EFBFBD>rler. RIGHT JO<EFBFBD>N t2'nin unjoined sat<EFBFBD>rlar<EFBFBD>n<EFBFBD> ekleyecektir.
Bir FULL join, e<EFBFBD>le<EFBFBD>mi<EFBFBD> b<EFBFBD>t<EFBFBD>n sat<EFBFBD>rlar<EFBFBD> ve t1 ile t2'den t<EFBFBD>m ba<EFBFBD>lanmam<EFBFBD><EFBFBD> (unjoined) sat<EFBFBD>rlar<EFBFBD> al<EFBFBD>r.
OUTER s<EFBFBD>zc<EFBFBD><EFBFBD><EFBFBD> se<EFBFBD>imseldir ve LEFT, RIGHT ve FULL join i<EFBFBD>lemlerinde oldu<EFBFBD>u kabul edilir. S<EFBFBD>radan
join i<EFBFBD>lemleri INNER join olarak adland<EFBFBD>r<EFBFBD>l<EFBFBD>r.
<EFBFBD>nceki s<EFBFBD>r<EFBFBD>mlerde, OUTER JOINler UNION ve NOT IN kullan<EFBFBD>larak sim<EFBFBD>le edilebiliyordu. <EFBFBD>rne<EFBFBD>in, tab1
ve tab2'yi birle<EFBFBD>tirirken, a<EFBFBD>a<EFBFBD><EFBFBD>daki sorgu iki tablonun d<EFBFBD><EFBFBD>tan ba<EFBFBD>lanmas<EFBFBD>n<EFBFBD> sa<EFBFBD>lar:
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 <EFBFBD>N (SELECT tab2.col1 FROM tab2)
Mevcut veritaban<EFBFBD>n<EFBFBD>z d<EFBFBD>s<EFBFBD>ndaki baska bir veritaban<EFBFBD>n<EFBFBD>z<EFBFBD> sorgulaman<EFBFBD>z<EFBFBD>n bir yolu bulunmamaktad<EFBFBD>r.
bunun nedeni, PostgreSQL'in veritaban<EFBFBD>na <EFBFBD>zel sistem kataloglar<EFBFBD> y<EFBFBD>klemesidir. Bu nedenle,
tabloya eri<EFBFBD>iyorsa ve bu tablo ileride kald<EFBFBD>r<EFBFBD>l<EFBFBD>p yeniden olu<EFBFBD>turulduktan sonra fonksiyon yeniden <EFBFBD>a<EFBFBD>r<EFBFBD>l<EFBFBD>rsa,
fonksiyon <EFBFBD>al<EFBFBD><EFBFBD>mayacakt<EFBFBD>r; <EFBFBD><EFBFBD>nk<EFBFBD> cachelenmi<EFBFBD> fonksiyon hala eski ge<EFBFBD>ici tabloyu g<EFBFBD>steriyor olacakt<EFBFBD>r. <EFBFBD><EFBFBD>z<EFBFBD>m,
Ayr<EFBFBD>ca,pg_hba.conf dosyas<EFBFBD> i<EFBFBD>inde host ya da hostssl kayd<EFBFBD> mutlaka olmal<EFBFBD>d<EFBFBD>r ve istemci sslmode
kapat<EFBFBD>lmamal<EFBFBD>d<EFBFBD>r. (Ayn<EFBFBD> zamanda,PostgreSQL'in do<EFBFBD>al SSL ba<EFBFBD>lant<EFBFBD>lar<EFBFBD> d<EFBFBD><EFBFBD><EFBFBD>nda ssh ya da ssl gibi 3.parti
<EFBFBD>ifrelenmi<EFBFBD> veri iletimi de m<EFBFBD>mk<EFBFBD>nd<EFBFBD>r.)
* Veritaban<EFBFBD> kullan<EFBFBD>c<EFBFBD> ad<EFBFBD> ve <EFBFBD>ifreleri 7.3 s<EFBFBD>r<EFBFBD>m<EFBFBD> ile birlikte otomatik olarak <EFBFBD>ifrelenirler. <EFBFBD>nceki
5.1) Kullan<EFBFBD>c<EFBFBD>-tan<EFBFBD>ml<EFBFBD> bir fonksiyon yazd<EFBFBD>m. psql'de <EFBFBD>al<EFBFBD><EFBFBD>t<EFBFBD>rd<EFBFBD><EFBFBD><EFBFBD>m zaman neden core dump ediyor?