From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Wolfgang(dot)Fuertbauer(at)ebewe(dot)com |
Cc: | pgsql-sql(at)postgresql(dot)org |
Subject: | Re: join-performance problem |
Date: | 2002-04-30 16:44:19 |
Message-ID: | 20730.1020185059@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
Wolfgang(dot)Fuertbauer(at)ebewe(dot)com writes:
>> explain SELECT b.Kdnr, date_part('year', b.Datum), d.Name, e.Name, a.Menge,
>> a.Rabproz, a.Netto - (a.netto * a.rabproz / 100),
>> a.Netto * b.kurs - ((a.netto * b.kurs) * a.rabproz / 100), 'RG'
>> FROM Faktzeilen a, Fakt b, Artikel c, Kollektion d, ArGruppen e
>> where a.Fanr = b.nr
>> and c.nr = a.Arnr
>> and c.Kollektion = d.Nr
>> and (c.Gruppe = e.nr or c.gruppe = 0)
>> and b.kdnr = 49736;
Anyplace that c.gruppe is 0, this is an unconstrained join to e --- ie,
you'll get a row out for *every* row of e. Somehow I doubt that's the
behavior you really want.
I concur with Stephan's observation that you haven't analyzed. But
even when you have, this query doesn't give much traction for the use
of indexes on a --- the only constraint that might possibly be used to
avoid a complete scan of a is the "b.kdnr = 49736", and that's not even
on a. The only hope I can see is if you create an index on b.kdnr;
then (if there aren't very many rows matching b.kdnr = 49736), it might
be able to pick those up with an indexscan on b and then do an inner
indexscan join to a using a.Fanr = b.nr. Your secondary indexes on a
look like wastes of space (at least for this query).
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | pgsql-bugs | 2002-04-30 18:15:19 | Bug #652: NAMEDATALEN limitations |
Previous Message | Stephan Szabo | 2002-04-30 15:58:09 | Re: join-performance problem |