From: | Manfred Koizar <mkoi-pg(at)aon(dot)at> |
---|---|
To: | "Booth, Robert" <Robert_Booth(at)intuit(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Query Analyzing |
Date: | 2002-07-17 09:35:38 |
Message-ID: | rrcajug3jo80tohqbm1g0f8fh6e1qcasqf@4ax.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, 8 Jul 2002 11:16:34 -0700, "Booth, Robert"
<Robert_Booth(at)intuit(dot)com> wrote:
>[about performance problems with a query containing two inner and
> eight outer joins]
Rob,
sorry for being quiet for so long, the printout of your mail got lost
in a pile of paper.
It wouldn`t have helped much, however, if I responded earlier. I
could not find a hot spot in your query, you are losing time
constantly, not much with each outer join, but it sums up.
Rewording your SQL won't help, AFAICS.
I thought of converting the outer joins to inner joins (you would have
to provide default entries in your lookup tables), writing the joins
in this form:
FROM a, b, c ... WHERE a.b_id=b.id AND a.c_id=c.id ...
and letting the optimizer do its work, but I fear that you would again
end up with lots of hash joins.
Maybe caching the lookup tables in the frontend might help?
Servus
Manfred
From | Date | Subject | |
---|---|---|---|
Next Message | stefan | 2002-07-17 10:14:10 | sequence id |
Previous Message | Martijn van Oosterhout | 2002-07-17 09:23:38 | Re: timestamped archive data index searches |