Re: Slow performance with left outer join

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Marten Verhoeven" <m(dot)verhoeven(at)van-beek(dot)nl>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Slow performance with left outer join
Date: 2008-01-21 16:55:55
Message-ID: 8283.1200934555@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

"Marten Verhoeven" <m(dot)verhoeven(at)van-beek(dot)nl> writes:
> This is the query analysis:

> Nested Loop Left Join (cost=1796.69..3327.98 rows=5587 width=516)
> Join Filter: (fpuarticle.a_no = fpuarticletext.at_a_no)
> Filter: (strpos(lower((((COALESCE(fpuarticle.a_code, ''::character varying))::text || ' '::text) || (COALESCE(fpuarticletext.at_text, ''::character varying))::text)), 'string'::text) > 0)
> -> Seq Scan on fpuarticle (cost=0.00..944.62 rows=16762 width=386)
> -> Materialize (cost=1796.69..1796.70 rows=1 width=130)
> -> Seq Scan on fpuarticletext (cost=0.00..1796.69 rows=1 width=130)
> Filter: ((COALESCE((at_type)::integer, 1) = 1) AND (COALESCE(at_language, 0::numeric) = 0::numeric))

If this is slow, it must be that the scan of fpuarticletext actually
returns many more rows than the single row the planner is expecting.
The reason the estimate is off is probably that the planner cannot make
any useful estimate about those COALESCE expressions. Try rewriting
them in the simpler forms

(at_type = 1 or at_type is null) AND
(at_language = 0 or at_language is null)

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Pavel Stehule 2008-01-21 18:04:33 Re: Slow performance with left outer join
Previous Message Pavel Stehule 2008-01-21 15:17:16 Re: Slow performance with left outer join