Re: Strange workaround for slow query
От | Yeb Havinga |
---|---|
Тема | Re: Strange workaround for slow query |
Дата | |
Msg-id | 4B977045.6040604@gmail.com обсуждение исходный текст |
Ответ на | Re: Strange workaround for slow query (sverhagen@wps-nl.com) |
Ответы |
Re: Strange workaround for slow query
|
Список | pgsql-performance |
sverhagen@wps-nl.com wrote: > > Hi, > > > EXPLAIN SELECT * FROM events_events LEFT OUTER JOIN events_event_types ON > eventType_id=events_event_types.id WHERE severity=20 AND (eventType_id > IN (71)) ORDER BY datetime DESC limit 50; > QUERY PLAN > ------------------------------------------------------------------------------------------------------------------------------------------- > Limit (cost=3.23..200.31 rows=50 width=131) > -> Nested Loop (cost=3.23..49139.16 rows=12466 width=131) > -> Index Scan Backward using events_events_eventtype_id_datetime_ind > on events_events (cost=0.00..48886.61 rows=12466 width=93) > Index Cond: (eventtype_id = 71) > -> Materialize (cost=3.23..3.24 rows=1 width=38) > -> Seq Scan on events_event_types (cost=0.00..3.23 rows=1 width=38) > Filter: ((id = 71) AND (severity = 20)) > > > EXPLAIN SELECT * FROM events_events LEFT OUTER JOIN events_event_types ON > eventType_id=events_event_types.id WHERE severity=70 AND (eventType_id > IN (71, 999)) ORDER BY datetime DESC LIMIT 50; > QUERY PLAN > ------------------------------------------------------------------------------------------------------------------------------------------------------------ > Limit (cost=27290.24..27290.37 rows=50 width=131) > -> Sort (cost=27290.24..27303.15 rows=5164 width=131) > Sort Key: events_events.datetime > -> Nested Loop (cost=22.95..27118.70 rows=5164 width=131) > -> Seq Scan on events_event_types (cost=0.00..3.02 rows=17 width=38) > Filter: (severity = 70) > -> Bitmap Heap Scan on events_events (cost=22.95..1589.94 rows=408 > width=93) > Recheck Cond: ((events_events.eventtype_id = ANY > ('{71,999}'::bigint[])) AND (events_events.eventtype_id = > events_event_types.id)) > -> Bitmap Index Scan on test_events_events_eventtype_id_severity_ind > (cost=0.00..22.85 rows=408 width=0) > Index Cond: ((events_events.eventtype_id = ANY ('{71,999}'::bigint[])) > AND (events_events.eventtype_id = events_event_types.id)) > Thanks - I'm sorry that I was not more specific earlier, but what would be *really* helpful is the output of explain analyze, since that also shows actual time, # rows and # loops of the inner nestloop. I'm wondering though why you do a left outer join. From the \d output in the previous mail, events_event.eventtype_id has a not null constraint and a fk to events_event_types.id, so an inner join would be appropriate. Outer joins limits the amount of join orders the planner considers, so a better plan might arise when the join is changed to inner. regards Yeb Havinga
В списке pgsql-performance по дате отправления: