Teradata does not support hints to the optimizer. So there is no mechanism to say don’t use a sliding window join.
In general, a sliding window join is beneficial as it joins the two tables without having to spool either of them. It is a PPI-aware merge join. However, it may be slower than the traditional merge join or the rowkey-based merge join when there are many noneliminated, nonempty combined partitions.
So if it is a particular query that you are having problems with and it is getting a sliding-window, the options would be to try changing the partitioning or indexes of the tables, collecting statistics (or dropping statistics), adding a join index or secondary index, or if the query can be changed possibly fiddling with the query.
If you believe that the sliding window is not the optimal plan for a query, and that the optimizer should be choosing a different type of join or join sequence, please submit an incident.
Thanks, -Carrie
Teradata does not support hints to the optimizer. So there is no mechanism to say don’t use a sliding window join.
In general, a sliding window join is beneficial as it joins the two tables without having to spool either of them. It is a PPI-aware merge join. However, it may be slower than the traditional merge join or the rowkey-based merge join when there are many noneliminated, nonempty combined partitions.
So if it is a particular query that you are having problems with and it is getting a sliding-window, the options would be to try changing the partitioning or indexes of the tables, collecting statistics (or dropping statistics), adding a join index or secondary index, or if the query can be changed possibly fiddling with the query.
If you believe that the sliding window is not the optimal plan for a query, and that the optimizer should be choosing a different type of join or join sequence, please submit an incident.
Thanks, -Carrie