DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:user-agent:mime-version:to:cc:subject
	:references:in-reply-to:content-type:content-transfer-encoding;
	b=YY6+GQ4XkuYq3hqVpo2Jp7R4WDH/s9OIpi07J7QRSPEvhCwNgNJh+sH7oJMxfDOS83
	F/Jfw0yeFhPG2yB2/jcfFNb23/zbiRdOUStjwKCGhuT3jdP2SwqMD3l+SnIyO83Qdi9m
	NiXOcczoRk3Jcyo0VfBCiSmbKhIjYb+p3u6mY=
Message-ID: <4B977045.6040604@gmail.com>
Date: Wed, 10 Mar 2010 11:11:17 +0100
From: Yeb Havinga <yebhavinga@gmail.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: sverhagen@wps-nl.com
CC: pgsql-performance@postgresql.org
Subject: Re: Strange workaround for slow query
References: 
 <OF6136AD9B.D40F3AF5-ONC12576E2.002D5763-C12576E2.002FBD70@imtechrelay.nl>
	<4B976229.7030407@gmail.com>
	<OFAD6B66E9.A0DAC161-ONC12576E2.0033EEEB-C12576E2.0033F903@imtechrelay.nl>
In-Reply-To: 
 <OFAD6B66E9.A0DAC161-ONC12576E2.0033EEEB-C12576E2.0033F903@imtechrelay.nl>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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