|
Archives of the TeradataForumMessage Posted: Thu, 10 Aug 2000 @ 12:26:15 GMT
Dave, My first guess is that the aliasing being done by BO is incomplete/incorrect and it's confusing Teradata's optimiser. For example, the following query will be treated by the optimiser as a three table join, looking for tables A, B and ORDERS (assuming that 'col4' only exists in one of the tables; Selecte a.col1, a.col2, b.col3, col4 From Orders A, Products B Where a.col1 = b.col1 and In this case, the optimiser finds 'col4' without an alias and so looks for it in the tables in the FROM clause. If it only finds it in one of the tables listed (e.g. ORDERS) then it's happy with that but decides that there are now three tables in the query (A, B and ORDERS). if you haven't got any join criteria between ORDERS and one of the other tables you suddenly get an unconstrained product join - much joy and lots of spool space being used ! Sound familiar? This could be one reason why removing the aliases brings the run-time back down to something maneagable. I've done a litle bit of work with BO and Teradata and haven't come across this as a specific BO issue (there are plenty of customers using that combination), but you might want to double check the BO-generated sql. I hope that helps, if not let us know and we'll have another go. Cheers, Dave
| ||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||
Copyright 2016 - All Rights Reserved | ||||||||||||||||||||||||||||||||||||||||||||||||
Last Modified: 15 Jun 2023 | ||||||||||||||||||||||||||||||||||||||||||||||||