Re: Чудо дивное планировщик явил !!!
От | Nikolay Samokhvalov |
---|---|
Тема | Re: Чудо дивное планировщик явил !!! |
Дата | |
Msg-id | e431ff4c0703280643tbb6afcbl9cc470922a213ee3@mail.gmail.com обсуждение исходный текст |
Ответ на | Чудо дивное планировщик явил !!! (silly_sad <sad@bankir.ru>) |
Список | pgsql-ru-general |
Какие колонки в article?
Наверняка там varlena-типы есть (varchar, text, bytea и тд). В таких случаях работает TOAST-инг. Когда выбираем все колонки -- Постгресу приходится залезать в toast-таблицу. Если всё так, то ничего удивительного не случилось.
Про TOAST тут: http://www.postgresql.org/docs/8.2/interactive/storage-toast.html
--
Best regards,
Nikolay
Наверняка там 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@bankir.ru> wrote:
hi all
Вот два эксплэйна, не спешите копаться в их WHERE хотя это и любопытно,
но не так сильно...
обратите внимание что запросы отличаются ТОЛЬКО СЕЛЕКТ-ЛИСТОМ
в первом запросе, который выполняется в 30 раз быстрее, выбираются все
поля, а во втором, выбирается только одно поле (которое входит также и в
первый запрос)
и откуда же происходит такая радикальная разница в планах ????
cms1=> EXPLAIN ANALYZE SELECT * from article as a, (select st.id as
stid, 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 from article as a, (select st.id as
stid, 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
В списке pgsql-ru-general по дате отправления: