From: Serdar KÖYLÜ (serdarkoylu@fisek.com.tr)
Date: Fri 25 Mar 2005 - 11:23:26 EET
Selamlar..
Eger, INT_MAX (32 Bit) sinirlarinda bir PGresult'unuz varsa, yani bir
sorgu yaptiniz ve sonuc 2^31 adet satir iceriyorsa, burada bir baska
sorun vardir. Bu kadar buyuk bir result'u nasil handle edeceksiniz?
Belleginiz, diskiniz vs? Bu sorgulamanin her satiri sadece 1 bayt olsa,
sizde bunlari kagida yazmaya ciksaniz, (2^32) / 80 * 66, 450000 sayfa
filan eder saniyorum.
Bu tur yuksek yuk durumlarinda, sorgulama islevinin daha makul bir yolla
sadece gereken veriyi icerecek sekilde yapilmasi gerekir. Ornegin, siz
ilk 10 sayfayi okursunuz. Bunlari yaziciya yollar, o yazarken bir
sonraki 10 sayfayi okursunuz. Boylece, sorgulamayi bekle, yaziciyi
bekle... gibi gereksiz zaman kaybini engellersiniz.
Tamam, tabloyu tek tek yazmayacagiz, bir field'in toplamini bulacagiz. O
zamanda cozum, bu fielde deger atarken, trigger vs. kod yoluyla bu
toplami bir baska yerde tutmak olur.
Dusunulmesi gereken limitler, mimari limitlerinden once, gercek hayatin
limitleridir: Kullanicinin sabrinin limitleri, mesai saati limitleri,
network limitleri vs.
Saygi ve sevgiler..
> Merhaba,
>
> Bugün PQgetvalue() fonksiyonunu inceliyordum ve sanırım ufak (!)
> bir duvar ile karşılaştım.
>
>
> Önerme 1:
> Fiziksel depolama alanınız yettiği sürece, istediğiniz kadar
> satır saklayabilirsiniz bir PostgreSQL tablosunda. Yani
> teorik olarak sınırsız.
>
>
> Önerme 2:
> src/interfaces/libpq/fe-exec.c dosyasında tanımlanan PQgetvalue
> fonksiyonuna bakıyoruz:
>
> char *
> PQgetvalue(const PGresult *res, int tup_num, int field_num)
> {
> if (!check_tuple_field_number(res, tup_num, field_num))
> return NULL;
> return res->tuples[tup_num][field_num].value;
> }
>
> Görüldüğü üzere, tup_num (satır indisi) bir integer olarak tanımlanmış.
> Ve istediğimiz satırı "res->tuples[tup_num][field_num].value;"
> yordamı yardımı ile çağırıyoruz.
>
> Şimdi bu bir kenarda dursun: satır numarası bir integer olarak
> tanımlı.
>
>
> Önerme 3:
> Sistemde limits.h dosyasına bakıyoruz:
>
> /* Minimum and maximum values a `signed int' can hold. */
> # define INT_MIN (-INT_MAX - 1)
> # define INT_MAX 2147483647
>
> Bu da bir kenarda dursun: Sistem kullanılabilecek en büyük integer
> değeri: 2147483647
>
>
> libpq çıkmazı: Eğer ben bir tablodaki 2147483647+1 inci satırı öğrenmeye
> çalışırsam halim yaman.
>
> Ufak bir nokta daha var. tuples'in yüklü bir struct olduğu göz önüne
> alınırsa, tuples[INT_MAX][INT_MAX] büyüklüğünde bir çağrı ne derece
> çalşır? (Bkz. Basit bir "short buf[INT_MAX]" oluşturma örneği.)
>
> Aslında bu resmin sadece küçük bir parçası. Şöyle ki; piyasadaki
> API'lerin %99'unun libpq'yu kendilerine baz aldıkları düşünülecek
> olursa, onların hepsinde de bu (eğer düşüncem doğruysa) sınırlama
> mevcut.
>
> Sanırım sorum şimdilik bu kadar.
> Yorum, öneri ve en önemlisi can simitlerinizi bekliyorum.
>
> P.S. Lütfen ben bir noktayı gözden kaçırmış olayım. API kullanacak
> insanların dünyası sınırlanmasın. :P
>
> ______________________________________________________________________
> _______________________________________________
> Linux-programlama mailing list
> Linux-programlama@liste.linux.org.tr
> http://liste.linux.org.tr/mailman/listinfo/linux-programlama
_______________________________________________
Linux-programlama mailing list
Linux-programlama@liste.linux.org.tr
http://liste.linux.org.tr/mailman/listinfo/linux-programlama