From: | Anton <anton200(at)gmail(dot)com> |
---|---|
To: | "Teodor Sigaev" <teodor(at)sigaev(dot)ru> |
Cc: | pgsql-ru-general(at)postgresql(dot)org |
Subject: | Re: SELECT ... WHERE ... IN (SELECT ...) -> SELECT ... WHERE (... OR ... ) |
Date: | 2006-12-05 09:34:00 |
Message-ID: | 8cac8dd0612050134j39c6b880ye3d490eb9df51fa3@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-ru-general |
> А если в этом запросе отключить nested_join?
> set enable_nestloop=off;
Кажется я нашёл причину.
Дело принимает такой долгий оборот когда в таблице n_traffic нет
записей для тех логинов по которым ищется информация.
Может быть на основе статистики постгрес делает вывод "проверить по
полной на всякий случай" и проходит полностью по n_traffic.
А когда есть хотя бы одна запись, всё мигом делается:
=# explain analyze SELECT * FROM
billing-# (
billing(# SELECT collect_time FROM n_traffic
billing(# WHERE login_id IN (SELECT login_id FROM n_logins WHERE
account_id = '1655')
billing(# ) as t
billing-# WHERE collect_time > '1970-01-01' ORDER BY collect_time LIMIT 1;
---------------------------------------------------------
Limit (cost=0.00..2026.32 rows=1 width=8) (actual time=0.110..0.112
rows=1 loops=1)
-> Nested Loop IN Join (cost=0.00..911843.38 rows=450 width=8)
(actual time=0.104..0.104 rows=1 loops=1)
-> Index Scan using n_traffic_collect_time_login_id on
n_traffic (cost=0.00..11101.16 rows=284514 width=12) (actual
time=0.066..0.066 rows=1 loops=1)
Index Cond: (collect_time > '1970-01-01
00:00:00'::timestamp without time zone)
-> Index Scan using n_logins_pkey on n_logins
(cost=0.00..3.15 rows=1 width=4) (actual time=0.025..0.025 rows=1
loops=1)
Index Cond: ("outer".login_id = n_logins.login_id)
Filter: (account_id = 1655)
Total runtime: 0.407 ms
(8 rows)
--
engineer
From | Date | Subject | |
---|---|---|---|
Next Message | Anton | 2006-12-11 18:10:12 | index на таблицу с ~ 700 000 записей: чем занят постгрес??? |
Previous Message | Sergey Suleymanov | 2006-12-05 08:10:49 | Re: SELECT ... WHERE ... IN (SELECT ...) -> |