Re: select * from udr.vhastakayit limit 100

aynı view da select çektiğinizde neye göre seqscan,idxscan yapar ki?
bir de deneme yanılma yöntemiyle şunu buldum. limit 124 e kadar yavaş,
limit 125 yaptığınız da hızlanıyor. Ne alaka çözemedim. limit 125 ten
sonrasında bir sorun yok.
aynı tablolarla yeni bir view oluşturdum yine aynı. tabloların bağlantı
alanları index li.

-- Executing query:
select * from udr.qq limit 124

Total query runtime: 10178 ms.
124 rows retrieved.

-- Executing query:
select * from udr.qq limit 125

Total query runtime: 842 ms.
125 rows retrieved.

--
Namık Güngör
Ofis İletişim Bilgisayar San.Tic.Ltd.Şti.
İzzetpaşa Mah. Yeniyol Cd. No:4/2
34387 Şişli - İstanbul
Tel : +90 212 219 88 77
Faks : +90 212 219 88 80

namik(at)ofisiletisim(dot)com
www.ofisiletisim.com

toplam kayıt sayısı, indexler, offset, limit ve sorguya göre hangi
yöntem ile sonucun hızlı bir şekilde üretileceğine karar verip o
yöntemi uyguluyor, offset 0 limit 24 ile offset 1000 limit 24 arasında
da query plan farklı olabilir. Tablolarınızın istatistiklerini[0]
update ederek daha iyi bir sorgu planı çıkartılmasını
sağlayabilirsiniz.

[1] adresinde verilen query planner parametrelerini SET ile açıp
kapatarak sorgunuzun istediğiniz bir yöntem kullanılarak
çalıştırılmasını sağlayabilirsiniz.

[0] http://www.postgresql.org/docs/8.4/interactive/sql-analyze.html
[1] http://www.postgresql.org/docs/8.4/interactive/runtime-config-query.html

2010/3/31 Namık Güngör <namik(at)ofisiletisim(dot)com>:
> aynı view da select çektiğinizde neye göre seqscan,idxscan yapar ki?
> bir de deneme yanılma yöntemiyle şunu buldum. limit 124 e kadar yavaş, limit
> 125 yaptığınız da hızlanıyor. Ne alaka çözemedim. limit 125 ten sonrasında
> bir sorun yok.
> aynı tablolarla yeni bir view oluşturdum yine aynı. tabloların bağlantı
> alanları index li.
>
> -- Executing query:
> select * from udr.qq limit 124
>
> Total query runtime: 10178 ms.
> 124 rows retrieved.
>
> -- Executing query:
> select * from udr.qq limit 125
>
> Total query runtime: 842 ms.
> 125 rows retrieved.
>
> --
> Namık Güngör
> Ofis İletişim Bilgisayar San.Tic.Ltd.Şti.
> İzzetpaşa Mah. Yeniyol Cd. No:4/2
> 34387 Şişli - İstanbul
> Tel   : +90 212 219 88 77
> Faks : +90 212 219 88 80
>
> namik(at)ofisiletisim(dot)com
> www.ofisiletisim.com
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe ve unsubscribe komutlarını
> majordomo(at)postgresql(dot)org
>
>

--
Saygılar && İyi Çalışmalar
Timu EREN ( a.k.a selam )

Sorgularda bildiğiniz gibi optimizer bir maliyet hesabı yapar. Ve biliyorsunuz index kullanıldığı zaman hem index ve hem de data okunur. Bu durumda 2 defa disk ulaşımı yapılır. Optimizer, bu aradaki maliyeti hesaplar ve bir karar verir. Optimizer ın kararının doğruluğu, istatistik kayıtlarının gerçeğe yakınlığıyla alakalıdır. İstatistik tabloları da ANALYZE komutuyla güncellenir.

İyi Çalışmalar
Adnan DURSUN
ASRIN Bilişim Ltd.Şti.

> Date: Wed, 31 Mar 2010 10:38:45 +0300
> From: namik(at)ofisiletisim(dot)com
> To: pgsql-tr-genel(at)postgresql(dot)org
> Subject: [pgsql-tr-genel] select * from udr.vhastakayit limit 100
>
> aynı view da select çektiğinizde neye göre seqscan,idxscan yapar ki?
> bir de deneme yanılma yöntemiyle şunu buldum. limit 124 e kadar yavaş,
> limit 125 yaptığınız da hızlanıyor. Ne alaka çözemedim. limit 125 ten
> sonrasında bir sorun yok.
> aynı tablolarla yeni bir view oluşturdum yine aynı. tabloların bağlantı
> alanları index li.
>
> -- Executing query:
> select * from udr.qq limit 124
>
> Total query runtime: 10178 ms.
> 124 rows retrieved.
>
> -- Executing query:
> select * from udr.qq limit 125
>
> Total query runtime: 842 ms.
> 125 rows retrieved.
>
> --
> Namık Güngör
> Ofis İletişim Bilgisayar San.Tic.Ltd.Şti.
> İzzetpaşa Mah. Yeniyol Cd. No:4/2
> 34387 Şişli - İstanbul
> Tel : +90 212 219 88 77
> Faks : +90 212 219 88 80
>
> namik(at)ofisiletisim(dot)com
> www.ofisiletisim.com
>
>

_________________________________________________________________
Hotmail: Trusted email with powerful SPAM protection.
https://signup.live.com/signup.aspx?id=60969

Namik Bey,
hafiza ve CPU kullanimina bakabilirmisiniz, orda tam olarak ne yaptigini
göstermesi gerekir.

--
iyi günler
Ahmet Tat
Software Architect

2010/3/31 Namık Güngör <namik(at)ofisiletisim(dot)com>

> aynı view da select çektiğinizde neye göre seqscan,idxscan yapar ki?
> bir de deneme yanılma yöntemiyle şunu buldum. limit 124 e kadar yavaş,
> limit 125 yaptığınız da hızlanıyor. Ne alaka çözemedim. limit 125 ten
> sonrasında bir sorun yok.
> aynı tablolarla yeni bir view oluşturdum yine aynı. tabloların bağlantı
> alanları index li.
>
> -- Executing query:
> select * from udr.qq limit 124
>
> Total query runtime: 10178 ms.
> 124 rows retrieved.
>
> -- Executing query:
> select * from udr.qq limit 125
>
> Total query runtime: 842 ms.
> 125 rows retrieved.
>
> --
> Namık Güngör
> Ofis İletişim Bilgisayar San.Tic.Ltd.Şti.
> İzzetpaşa Mah. Yeniyol Cd. No:4/2
> 34387 Şişli - İstanbul
> Tel : +90 212 219 88 77
> Faks : +90 212 219 88 80
>
> namik(at)ofisiletisim(dot)com
> www.ofisiletisim.com
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe ve unsubscribe komutlarını
> majordomo(at)postgresql(dot)org
>
>

--
iyi günler
Ahmet Tat
Software Architect