EMAIL PROTECTED]]
Sent: Tuesday, January
17, 2006
7:25 PM
To:
derby-dev@db.apache.org
Subject: Re:
Optimizing subqueries
[ Was: Re: VTI, Indexed Lookup and the Query Optimizer ]
Hi Jeff,
Jeffrey Lichtman wrote:
Unfortunately,
I don't
remember why hash joins are prohibited in
created? Is
it created after one complete scan based on the query pattern?
From: Satheesh Bandaram [mailto:[EMAIL PROTECTED]
Sent: Tuesday, January 17, 2006
7:25 PM
To: derby-dev@db.apache.org
Subject: Re: Optimizing subqueries
[ Was: Re: VTI, Indexed Lookup and the Query Optimizer
Sorry - I somehow deleted part of my last message before sending it.
I'll try again:
The actual query that prompted this question, though, has a subquery
that uses aggregates and a GROUP BY--i.e. the subquery *cannot*, as
I understand it, be flattened into the outer query, because the
aggrega
Hi Jeff,
Jeffrey Lichtman wrote:
Unfortunately, I don't remember why hash joins are
prohibited in this case. One thing I notice in looking at the code is
the following in HashJoinStrategy.feasible():
Did you forget to cut_and_paste something from
HashJoinStrategy.feasible()? You said yo
The actual query that prompted this question, though, has a subquery
that uses aggregates and a GROUP BY--i.e. the subquery *cannot*, as
I understand it, be flattened into the outer query, because the
aggregate/group-by functionality has to be performed before
evaluation of the outer query ca
Jeffrey Lichtman wrote:
Based on logic in the code, the example query isn't flattenable. . .
That's because whoever wrote the code made it handle only the simplest
case. I doubt it would be hard to make it flatten many other types of
table subqueries.
The example I gave was a simplified s
