2003 1:26 PM
> To: 'Tom Lane'; Thomas Beutin
> Cc: [EMAIL PROTECTED]
> Subject: RE: [GENERAL] left outer join terrible slow compared to inner
> join
>
>
> Actually, I was about to post some problems we have with
> large left outer joins as well we've di
> And doing the explicit cross join statement on o_kat_prod instead of
> ot_kat_prod gives the expected performance to me ( 7.42 msec instead
> of 7324.49 msec with EXPLAIN ANALYZE).
>
> Do i've any chance to get the same performance on the view?
I've had this problem and it was due to improper ty
Greg Stark <[EMAIL PROTECTED]> writes:
> Now, uh, there are 37 tables involved in this query. That's kind of a lot.
> Postgres has to consider 37 factorial different ways of combining these
> tables. or about 13,763,750,000,000,000,000,000,000,000,000,000,000,000,000
> different combinations.
Of
Sent: Thursday, August 28, 2003 8:20 PM
> To: Mike Mascari
> Cc: Clay Luther; Greg Stark; [EMAIL PROTECTED]
> Subject: Re: [GENERAL] left outer join terrible slow compared to inner
> join
>
>
>
> Mike Mascari <[EMAIL PROTECTED]> writes:
>
> > > 1
Mike Mascari <[EMAIL PROTECTED]> writes:
> > 1) Our database is highly normalized.
If anything I was worried it was "excessively" normalized. Sometimes people go
overboard, taking columns that really could be simple attributes and make them
reference tables. But that usually doesn't cause perfor
Clay Luther wrote:
> Heh...well, first let me say:
>
> 1) Our database is highly normalized.
Excellent. When faced with the choice of ensuring integrity myself in
the face of redundancy vs. Tom Lane's ability to improve the planner,
optimizer, and executor, I always vote for the latter!
> 2) Al
Thomas Beutin <[EMAIL PROTECTED]> writes:
> i've a speed problem withe the following statement:
> SELECT DISTINCT pz.l1_id, pz.l2_id, pz.l3_id, pz.l4_id
> FROM ot_adresse AS a, ot_produkt AS p
> LEFT OUTER JOIN ot_kat_prod AS pz ON ( p.p_id = pz.p_id )
> WHERE p.a_id = a.id AND a.id = '1053911054
