Hi Brent,
Sounds like you're off to a good start. From the initial bug report, it
looks like there's a good idea about which heuristic is being
mis-applied here. Once you've studied the optimizer papers, I recommend
that you post some high-level candidate solutions. Try to avoid
optimizer jargon and concentrate on simple descriptions:
o What query plan would you rather see?
o What heuristic would the optimizer apply that would lead it to your
preferred plan?
o How would the optimizer decide to apply the new heuristic rather than
the old one?
I think you'll get some good feedback if your post contains the phrase
"Attention, optimizer experts." I think that the optimizer enthusiasts
on the list will give you good feedback:
o Maybe they can think of a better query plan or heuristic.
o Maybe they can see some awkward corner cases in your heuristic.
o They can advise you on whether your heuristic will short-circuit other
optimizer choices.
o They can advise you on whether your heuristic will cause an explosion
in the time that the optimizer takes.
Thanks for wanting to scratch this itch!
Regards,
-Rick
Brent Verner wrote:
Hi,
I've recently found need for an embedded java db and only Derby seems
even close to handling the task, however the broken query planning for IN
clauses makes it unusable :-(. I've decided to eschew an embedded db
in favor of PG for now, but I'd really like to be able to use Derby in the
near(ish) future for deployment.
I'd like to try to fix the query planning around the IN clause. I'm
reviewing the internals papers right now, but I'd appreciate any input
that might point me in the right direction :-).
cheers!
Brent
