Skip site navigation (1) Skip section navigation (2)

Re: Чудо дивное планировщик явил !!!

From: silly_sad <sad(at)bankir(dot)ru>
To: nikolay(at)samokhvalov(dot)com
Cc: pgsql-ru-general(at)postgresql(dot)org
Subject: Re: Чудо дивное планировщик явил !!!
Date: 2007-03-28 13:50:16
Message-ID: 460A7298.1060507@bankir.ru (view raw or flat)
Thread:
Lists: pgsql-ru-general
Nikolay Samokhvalov wrote:
> Какие колонки в article?
> Наверняка там varlena-типы есть (varchar, text, bytea и тд). В таких

Есть. и много.

> случаях работает TOAST-инг. Когда выбираем все колонки -- Постгресу
> приходится залезать в toast-таблицу. Если всё так, то ничего
> удивительного не случилось.

Если это неудивительно и вы ожидали такой эффект, то скажите:
какой запрос по-вашему должен быть тормознутее ?

> Про TOAST тут:
> http://www.postgresql.org/docs/8.2/interactive/storage-toast.html
> 
> On 3/28/07, * silly_sad* <sad(at)bankir(dot)ru <mailto:sad(at)bankir(dot)ru>> wrote:
> 
>     hi all
> 
>     Вот два эксплэйна, не спешите копаться в их WHERE хотя это и любопытно,
>     но не так сильно...
>     обратите внимание что запросы отличаются ТОЛЬКО СЕЛЕКТ-ЛИСТОМ
>     в первом запросе, который выполняется в 30 раз быстрее, выбираются все
>     поля, а во втором, выбирается только одно поле (которое входит также и в
>     первый запрос)
>     и откуда же происходит такая радикальная разница в планах ????
> 
> 
> 
>     cms1=> EXPLAIN ANALYZE SELECT * from article as a,  (select st.id
>     <http://st.id> as
>     stid, t1.id <http://t1.id>, t1.title FROM topic as t1, topic as st
>     WHERE t1.up=304532
>     and st.trail <@ t1.trail) as t where a.topic=t.stid;
> 
>                                    QUERY PLAN
> 
> 
>     Hash Join  (cost=30877.69..31472.42 rows=432 width=844) (actual
>     time=1.113..11.370 rows=745 loops=1)
>        Hash Cond: ("outer".topic = "inner".id)
>        ->  Seq Scan on article a  (cost= 0.00..566.94 rows=4694 width=824)
>     (actual time=0.006..4.328 rows=4692 loops=1)
>        ->  Hash  (cost=30856.18..30856.18 rows=8604 width=20) (actual
>     time=1.089..1.089 rows=30 loops=1)
>              ->  Nested Loop  (cost= 4.33..30856.18 rows=8604 width=20)
>     (actual time=0.106..1.046 rows=30 loops=1)
>                    ->  Index Scan using topic_up_idx on topic t1
>     (cost=0.00..346.48 rows=92 width=59) (actual time=0.017..0.041 rows=16
>     loops=1)
>                          Index Cond: (up = 304532)
>                    ->  Bitmap Heap Scan on topic st  (cost=4.33..330.45
>     rows=94 width=47) (actual time=0.055..0.057 rows=2 loops=16)
>                          Recheck Cond: ( st.trail <@ "outer".trail)
>                          ->  Bitmap Index Scan on topic_trail_idx
>     (cost=0.00..4.33 rows=94 width=0) (actual time=0.053..0.053 rows=2
>     loops=16)
>                                Index Cond: ( st.trail <@ "outer".trail)
>     Total runtime: 11.886 ms
>     (12 rows)
> 
> 
>     cms1=> EXPLAIN ANALYZE SELECT t.id <http://t.id> from article as
>     a,  (select st.id <http://st.id> as
>     stid, t1.id <http://t1.id>, t1.title FROM topic as t1, topic as st
>     WHERE t1.up=304532
>     and st.trail <@ t1.trail) as t where a.topic=t.stid;
> 
>                         QUERY PLAN
> 
> 
>     Nested Loop  (cost= 6294.70..16331.26 rows=432 width=4) (actual
>     time=227.417..314.261 rows=745 loops=1)
>        Join Filter: ("inner".trail <@ "outer".trail)
>        ->  Bitmap Heap Scan on topic t1  (cost=2.32..322.30 rows=92
>     width=47) (actual time=0.036..0.076 rows=16 loops=1)
>              Recheck Cond: (up = 304532)
>              ->  Bitmap Index Scan on topic_up_idx  (cost=0.00..2.32 rows=92
>     width=0) (actual time=0.029..0.029 rows=16 loops=1)
>                    Index Cond: (up = 304532)
>        ->  Materialize  (cost=6292.38..6339.32 rows=4694 width=43) (actual
>     time=0.853..16.298 rows=4692 loops=16)
>              ->  Merge Join  (cost=853.19..6287.69 rows=4694 width=43)
>     (actual time=13.633..218.724 rows=4692 loops=1)
>                    Merge Cond: ("outer".id = "inner".topic)
>                    ->  Index Scan using topic_pkey on topic st
>     (cost= 0.00..5130.78 rows=93527 width=47) (actual time=0.075..141.011
>     rows=93526 loops=1)
>                    ->  Sort  (cost=853.19..864.93 rows=4694 width=4) (actual
>     time=13.536..15.858 rows=4692 loops=1)
>                          Sort Key: a.topic
>                          ->  Seq Scan on article a  (cost=0.00..566.94
>     rows=4694 width=4) (actual time=0.005..7.273 rows=4692 loops=1)
>     Total runtime: 315.343 ms
>     (14 rows)
> 
>     ---------------------------(end of
>     broadcast)---------------------------
>     TIP 4: Have you searched our list archives?
> 
>                    http://archives.postgresql.org
> 
> 
> 
> 
> -- 
> Best regards,
> Nikolay


In response to

Responses

pgsql-ru-general by date

Next:From: silly_sadDate: 2007-03-29 05:21:44
Subject: Re: Чудо дивное планировщик явил !!!
Previous:From: Nikolay SamokhvalovDate: 2007-03-28 13:43:13
Subject: Re: Чудо дивное планировщик явил !!!

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group