Bryan,
This does look similar but I have noticed a difference. The estimated optimizer
cost remains exactly the same at 303.76 for whether joinOrder is specified or
not. A colleague noted this earlier today:
I don't see the any differences between the cost based optimizer and
the fix ordered query plans, but the fix ordered is so much faster.
10.4.2 didn't help and an interesting thing is that as I decrease the number
of tables, the response time gets better which means sense because of less
permutation that it has to generate for query plan. I'm not sure why the
query plans are the same, but the response times are so drastic unless
I'm reading the query plans incorrect or there is a bug that derby is not
actually doing what is in the query plan.
Is this the same defect with slightly different symptoms maybe? Also, Jira does
not note that 10.4, which we are using. Have you been able to reproduce your
issue in 10.4?
Dustin
-----Original Message-----
From: Bryan Pendleton [mailto:[email protected]]
Sent: Wednesday, February 18, 2009 2:09 PM
To: Derby Discussion
Subject: Re: Query Compilation Drastically Increased on Join
> offering. We have recently modified a query by adding a couple of
> tables to a simple join. We have noticed a drastic increase in query
> compilation time on large data sets.
It's possible you're seeing this problem:
https://issues.apache.org/jira/browse/DERBY-2130
There is an experimental patch attached to that issue. If possible,
in your environment, it would be interesting if you can confirm
whether the patch improves the behavior that you see.
thanks,
bryan
