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

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