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
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>
SELECT ... -- select all columns but the one you want to remove
INTO TABLE new_table
FROM old_table;
DROP TABLE old_table;
ALTER TABLE new_table RENAME TO old_table;
COMMIT;
4.5) Bir sat<EFBFBD>r, tablo ve veritaban<EFBFBD> icin en fazla b<EFBFBD>y<EFBFBD>kl<EFBFBD>k nedir?
S<EFBFBD>n<EFBFBD>rlar:
Veritabani icin en fazla b<EFBFBD>y<EFBFBD>kl<EFBFBD>k nedir? S<EFBFBD>n<EFBFBD>rs<EFBFBD>z (4 TB'l<EFBFBD>k veritaban<EFBFBD> bulunmaktad<EFBFBD>r)
Bir tablo icin en fazla b<EFBFBD>y<EFBFBD>kl<EFBFBD>k nedir? 16 TB
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 cok fazla yere gereksinim duymazlar, ama indexlenmis veriyi tutacaklar<EFBFBD>ndan
b<EFBFBD>y<EFBFBD>k olabilirler.
NULL de<EFBFBD>erler bitmapler i<EFBFBD>inde tutulur; dolay<EFBFBD>s<EFBFBD>yla <EFBFBD>ok az yer kaplarlar.
4.7) Veritaban<EFBFBD>nda hangi tablo ya da indexlerin tan<EFBFBD>mland<EFBFBD>g<EFBFBD>n<EFBFBD> nasil g<EFBFBD>rebilirim?
psql, bu t<EFBFBD>r bilgileri g<EFBFBD>stermek i<EFBFBD>in, \ ile ba<EFBFBD>layan bir <EFBFBD>ok komut sunmaktad<EFBFBD>r.
\? komutu ile bu komutlar<EFBFBD> g<EFBFBD>rebilirsiniz. Ayr<EFBFBD>ca, bunlar<EFBFBD> a<EFBFBD><EFBFBD>klayan ve pg_ ile ba<EFBFBD>layan
<EFBFBD>ok say<EFBFBD>da sistem tablosu bulunmaktad<EFBFBD>r. Ayn<EFBFBD> zamanda, psql -l ile t<EFBFBD>m veritabanlar<EFBFBD>n<EFBFBD>
listeyelebirsiniz.
Ayr<EFBFBD>ca, pgsql/src/tutorial/syscat.source kodunu inceleyebilirsiniz. Bu dosya, veritaban<EFBFBD>
sistem dosyalarindan bilgiyi almak i<EFBFBD>in gereksinim duyulan bir <EFBFBD>ok SELECTleri g<EFBFBD>sterir.
4.8) Sorgular<EFBFBD>m cok yava<EFBFBD>, ya da indexlerimi kullanm<EFBFBD>yorlar. Neden?
Indexes are not automatically used by every query. Indexes are only used if the table is larger than a minimum size,
and the query selects only a small percentage of the rows in the table. This is because the random disk access caused
by an index scan can be slower than a straight read through the table, or sequential scan.
To determine if an index should be used, PostgreSQL must have statistics about the table. These statistics are
collected using VACUUM ANALYZE, or simply ANALYZE. Using statistics, the optimizer knows how many rows are in the
table, and can better determine if indexes should be used. Statistics are also valuable in determining optimal join
order and join methods. Statistics collection should be performed periodically as the contents of the table change.
Indexes are normally not used for ORDER BY or to perform joins. A sequential scan followed by an explicit sort is
usually faster than an index scan of a large table.
However, LIMIT combined with ORDER BY often will use an index because only a small portion of the table is returned.
In fact, though MAX() and MIN() don't use indexes, it is possible to retrieve such values using an index with ORDER
BY and LIMIT:
SELECT col
FROM tab
ORDER BY col [ DESC ]
LIMIT 1;
E<EFBFBD>er optimizer'in sequential scan i<EFBFBD>leminde hata yapt<EFBFBD><EFBFBD><EFBFBD>n<EFBFBD> d<EFBFBD><EFBFBD><EFBFBD>n<EFBFBD>yorsan<EFBFBD>z, SET enable_seqscan TO 'off' 'u kullan<EFBFBD>n<EFBFBD>z
ve index scan'in hala h<EFBFBD>zl<EFBFBD> olup olmad<EFBFBD><EFBFBD><EFBFBD>n<EFBFBD> g<EFBFBD>rmek i<EFBFBD>in testler yap<EFBFBD>n<EFBFBD>z.
LIKE ya da ~ gibi operatorler kullaniyorsan<EFBFBD>z, indeksler sadece a<EFBFBD>a<EFBFBD><EFBFBD>daki ko<EFBFBD>ullarda kullan<EFBFBD>labilir:
* Arama dizininin ba<EFBFBD><EFBFBD>, dizinin ba<EFBFBD><EFBFBD> ile ba<EFBFBD>lanmal<EFBFBD>d<EFBFBD>r. Yani,
o LIKE sorgular<EFBFBD> % ile ba<EFBFBD>lamamal<EFBFBD>d<EFBFBD>r.
o D<EFBFBD>zenli ifade sorgular<EFBFBD> ^ i<EFBFBD>e ba<EFBFBD>lamamal<EFBFBD>d<EFBFBD>r.
* Arama metni bir karakter s<EFBFBD>n<EFBFBD>f<EFBFBD> ile ba<EFBFBD>layamaz. <EFBFBD>rnek: [a-e]
* ILIKE ve ~* gibi b<EFBFBD>y<EFBFBD>k/k<EFBFBD><EFBFBD><EFBFBD>k harfe duyars<EFBFBD>z aramalar indekslerden yararlanmazlar. Onun yerine, b<EFBFBD>l<EFBFBD>m 4.12'de
It allows the handling of large join queries through nonexhaustive search.
4.12) D<EFBFBD>zenli ifade (Regular Expression) aramalar<EFBFBD>n<EFBFBD> ve b<EFBFBD>y<EFBFBD>k/k<EFBFBD><EFBFBD><EFBFBD>k harfe duyars<EFBFBD>z aramalar<EFBFBD> nasil yapabilirim?
Bu b<EFBFBD>y<EFBFBD>k(k<EFBFBD><EFBFBD><EFBFBD>k harfe duyarl<EFBFBD> aramalar i<EFBFBD>in indeksi nasil kullanabilirim?
~ 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:
CREATE INDEX tabindex on tab (lower(col));
4.13) Bir sorguda, bir alanin "NULL" oldugunu nasil ortaya <EFBFBD><EFBFBD>karabilirim?
Kolonu, IS NULL ve IS NOT NULL ile test edebilirsiniz.
4.14) <EFBFBD>esitli karakter tipleri aras<EFBFBD>ndaki farklar nelerdir?
<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.
4.15.1) Nasil serial/otomatik artan(auto-incrementing) bir alan yaratabilirim?
PostgreSQL'de SERIAL veri tipi vard<EFBFBD>r. Bu veri tipi bir sequence ve kolon <EFBFBD>zerinde bir indeks yarat<EFBFBD>r.
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 nasil alabilirim?
One approach is to retrieve the next SERIAL value from the sequence object with the nextval() function before
inserting and then insert it explicitly. Using the example table in 4.15.1, an example in a pseudo-language would
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.
4.15.3) currval() ve nextval() diger kullanicilara sorun yaratmaz m<EFBFBD>?
4.20) Neden large-object islemlerim, "invalid large obj descriptor"? hatas<EFBFBD>n<EFBFBD> veriyor?
Large object islemlerinizin uclarina, yani lo_open ... lo_close komutlar<EFBFBD>n<EFBFBD>n <EFBFBD>evresine,
BEGIN WORK ve COMMIT koyman<EFBFBD>z gerekmektedir;
Eger ODBC gibi bir istemci arabirimi kullan<EFBFBD>yorsan<EFBFBD>z, auto-commit'i kapatman<EFBFBD>z gerekebilir.
4.21) Su andaki zaman<EFBFBD><EFBFBD>ntan<EFBFBD>ml<EFBFBD> deger olarak kabul eden How do <EFBFBD> create a column that will default to the current time?
Alttakini kullanabilirsiniz:
CURRENT_TIMESTAMP:
CREATE TABLE test (x int, modtime timestamp DEFAULT CURRENT_TIMESTAMP );
4.22) Neden IN kullanan subquerylerim <EFBFBD>ok yavas?
Currently, we join subqueries to outer queries by sequentially scanning the result of the subquery for
each row of the outer query. IN' i EXISTS ile de<EFBFBD>i<EFBFBD>tirerek bir <EFBFBD><EFBFBD>z<EFBFBD>me ula<EFBFBD><EFBFBD>labilir.
SELECT *
FROM tab
WHERE col1 <EFBFBD>N (SELECT col2 FROM TAB2)
to:
SELECT *
FROM tab
WHERE EX<EFBFBD>STS (SELECT col2 FROM TAB2 WHERE col1 = col2)
Bu s<EFBFBD>n<EFBFBD>rlamay<EFBFBD> ilerdeki s<EFBFBD>r<EFBFBD>mlerimizde d<EFBFBD>zeltmeyi planlamaktay<EFBFBD>z.
4.23) Outer join islemini nasil yapabilirim?
PostgreSQL outer joins islemlerini SQL standartlar<EFBFBD>n<EFBFBD> kullanarak ger<EFBFBD>eklestirmektedir.
Asagida 2 <EFBFBD>rnek bulunmaktad<EFBFBD>r:
SELECT *
FROM t1 LEFT OUTER JO<EFBFBD>N t2 ON (t1.col = t2.col);
ya da
SELECT *
FROM t1 LEFT OUTER JO<EFBFBD>N t2 US<EFBFBD>NG (col);
Bu <EFBFBD>zdes sorgular t1.col ' i t2.col'ye join ederler ve ayn<EFBFBD> zamanda t1'deki unjoined sat<EFBFBD>rlar<EFBFBD>
Bir FULL join, e<EFBFBD>le<EFBFBD>mi<EFBFBD> bt<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)
ORDER BY col1
4.24) Ayni andan birden fazla veritabaninda nasil islem yapabilirim?
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,
cross-database bir sorgunun nasil davranacag<EFBFBD>n<EFBFBD> kestirmek zordur.
contrib/dblink fonksiyon <EFBFBD>a<EFBFBD>r<EFBFBD>lar<EFBFBD>n<EFBFBD> kullanarak cross-database sorgulara izin verid. Tabii ki,
bir istemci degisik veritabanlar<EFBFBD>na ayn<EFBFBD> anda erisim saglayabilir ve bilgiyi bu sekilde
birlestirebilir.
4.25) Bir fonksiyondan nas<EFBFBD>l <EFBFBD>oklu sat<EFBFBD>r ya da kolon d<EFBFBD>nd<EFBFBD>rebilirim?
7.3 s<EFBFBD>r<EFBFBD>m<EFBFBD>nde, bir fonksiyondan kolayl<EFBFBD>kla <EFBFBD>oklu sat<EFBFBD>r ya da s<EFBFBD>tun d<EFBFBD>nd<EFBFBD>rebilirsiniz.
4.26) Neden Pl/PgSQL fonksiyonlar<EFBFBD> i<EFBFBD>inden g<EFBFBD>venli bir <EFBFBD>ekilde tablo yaratma/kald<EFBFBD>rma i<EFBFBD>lemlerini yapam<EFBFBD>yoruz?
PL/PgSQL fonksiyon i<EFBFBD>erikleri cacheler. Bunun istenmeyen bir taraf<EFBFBD>, e<EFBFBD>er bir PL/PgSQL fonksiyonu ge<EFBFBD>ici bir
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,
ge<EFBFBD>ici tablo eri<EFBFBD>imleri i<EFBFBD>in PL/PgSQL'de EXECUTE kullanmakt<EFBFBD>r. Bu, sorgunun her seferinde yeniden i<EFBFBD>lenmesini
sa<EFBFBD>layacakt<EFBFBD>r.
4.27) Hangi replikasyon se<EFBFBD>enekleri bulunmaktad<EFBFBD>r?
<EFBFBD>e<EFBFBD>itli master/slave replikasyon se<EFBFBD>enekleri bulunmaktad<EFBFBD>r. Bunlar master veritaban<EFBFBD>n<EFBFBD>n veritaban<EFBFBD> de<EFBFBD>i<EFBFBD>ikliklerini
yaparken, slave sunucunun sadece veritaban<EFBFBD>nda okuma yapmas<EFBFBD>na izin verir.
* 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
s<EFBFBD>r<EFBFBD>mlerde, postgresql.conf i<EFBFBD>indeki PASSWORD_ENCRYPTION se<EFBFBD>ene<EFBFBD>ini aktif hale getirmeniz gerekmektedir.
* Sunucunun kendisini <EFBFBD>ifreli dosya sistemi <EFBFBD>zerinde <EFBFBD>al<EFBFBD><EFBFBD>t<EFBFBD>rabilirsiniz.