Re: [PERFORM] Strange workaround for slow query

2010-05-29 Thread Sander Verhagen
Tom Lane wrote on 10-03-2010 23:37:20: > Tom Lane > 10-03-2010 23:37 > > Right now, nodeNestloop is not really aware of whether the inner scan > depends on any parameters from the outer scan, so it's a bit hard to > determine whether the join can be abandoned. However, I have 9.1 > plans to ch

Re: [PERFORM] Strange workaround for slow query

2010-03-10 Thread Robert Haas
On Wed, Mar 10, 2010 at 5:37 PM, Tom Lane wrote: > Robert Haas writes: >> It does seem like once the materialize step is done we could notice >> that the tuplestore is empty and, given that uses no outer variables >> or parameters and therefore will never be re-executed, we could skip >> the rest

Re: [PERFORM] Strange workaround for slow query

2010-03-10 Thread Tom Lane
Robert Haas writes: > It does seem like once the materialize step is done we could notice > that the tuplestore is empty and, given that uses no outer variables > or parameters and therefore will never be re-executed, we could skip > the rest of the index scan. Yeah, the same thing occurred to me

Re: [PERFORM] Strange workaround for slow query

2010-03-10 Thread Robert Haas
On Wed, Mar 10, 2010 at 6:04 AM, Yeb Havinga wrote: > sverha...@wps-nl.com wrote: >> >> > 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 nestl

Re: [PERFORM] Strange workaround for slow query

2010-03-10 Thread Harald Fuchs
In article , sverha...@wps-nl.com writes: > 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)) ORDER BY > datetime DESC LIMIT 50; > Now I have at least two possibilities: > - Implementing the dummy

Re: [PERFORM] Strange workaround for slow query

2010-03-10 Thread Yeb Havinga
sverha...@wps-nl.com wrote: > 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. No problem at all. EXPLAIN ANALYZE SELECT * FROM events_

Re: [PERFORM] Strange workaround for slow query

2010-03-10 Thread sverhagen
> 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. No problem at all. EXPLAIN ANALYZE SELECT * FROM events_events LEFT OUTER JOIN events_

Re: [PERFORM] Strange workaround for slow query

2010-03-10 Thread Yeb Havinga
sverha...@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

Re: [PERFORM] Strange workaround for slow query

2010-03-10 Thread sverhagen
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 ---

Re: [PERFORM] Strange workaround for slow query

2010-03-10 Thread Yeb Havinga
Hello Sander, Can you post the explain plan output of these queries? 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; SELECT * FROM events_events LEFT OUTER JOIN