I should also add that I'm using embedded server and that I thought Teiid would naturally push down in parallel so I may have just messed up the configuration
May be using the hint MAKENOTDEP on the "b" will prohibit in making a dependent join?
> I'd like Teiid to pushdown executions to b in parallel to improve overall performance. Any thoughts?
Using the nested table contruct while logically correct does not force dependent join style behavior. This is because generally the left hand side will produce few rows and the right hand side is a nested table function, procedure, or other expensive operation.
So you should have an access pattern on b.c1, use the makeind hint on b, or the makedep hint on a rather than using the nested table. That will give you a dependent join plan that can be parallelized.
Hi guys. Adding the access pattern and changing the query to
select a.c1, a.c2, b.blah
from a inner join /*+ makedep */ b on b.c1=a.c1;
nearly did the trick. Ultimately, I am trying to drive a bunch of parallel API requests which must qualify b.c1. Under the new access pattern and hint, I get multiple queries pushed down of the form SELECT b.blah FROM b WHERE b.c1 IN (...). If supports IN is false or the max IN criteria size is set to 1, the push down query is something like SELECT b.blah FROM b WHERE b.c1=x OR b.c1=y... Weirdly, I get this form even if supportsOrCriteria is false.
If supportsInCriteria and supprotsOrCriteria are both false, I would have expected the push down to be a bunch of queries like
- SELECT b.blah FROM b WHERE b.c=x
- SELECT b.blah FROM b WHERE b.c=y
I just discovered that setting
in my translator does the trick.