Re: OUTER JOIN performance regression remains in 8.3beta4 - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: OUTER JOIN performance regression remains in 8.3beta4
Date
Msg-id 871w8qlt0c.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: OUTER JOIN performance regression remains in 8.3beta4  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: OUTER JOIN performance regression remains in 8.3beta4  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

> As an example, consider
>     t1 join t2 on (...) join t3 on (...) ... join t8 on (...)
> and for simplicity suppose that each ON condition relates the new
> table to the immediately preceding table, and that we can't derive
> any additional join conditions through transitivity.  

So the problem is that if we happen to have some x=<const> clause for any
variable listed in those join clauses then we drop that clause entirely and
end up delaying that join until the very end?

So is the fact that the user provided a useless clause the only information we
have that these tables might be related?

So if I write (along with some other joins):
t1 join t2 on (t1.x=t2.x) where t1.x=3

I'll get a different result than if I write
t1, t2 where t1.x=3 and t2.x=3

?

Perhaps we could be going the other direction and trying to add redundant
selectivity 1.0 clauses when we have multiple variables which come out to the
same value?

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication
support!


pgsql-hackers by date:

Previous
From: Gavin Sherry
Date:
Subject: Re: Dynamic Partitioning using Segment Visibility Maps
Next
From: Tom Lane
Date:
Subject: Re: Problem with CVS HEAD's handling of mergejoins