 |
 |
Archives of the TeradataForum
Message Posted: Wed, 05 Mar 2008 @ 10:16:54 GMT
| Subj: | | Re: MLOAD application phase |
| |
| From: | | Victor Sokovin |
| | I forgot to mention that we also changed the table to MULTISET and NUPI. I honestly don't think this played a major role because earlier on
we had set the table as above without partitions and performance did not improve. Unless a combination of PARTITIONS, MULTISET and NUPI made so
much of a difference. | |
I see. This was not clear from your previous brief posting so thank you for adding these bits, Omer. Well, I think if this tuning exercise is
worth doing then it is worth doing properly, and with one step at a time so that you can really get to the core of the problem. There are usually
no magic solutions for all possible problems (if there were such solutions Teradata would be the first to implement them, wouldn't they?). Your
current settings seem to have helped on the ETL side but watch out for the performance of queries and check regularly for possible duplicates.
I must admit I am still curious as to what influence the existing data in the table had on the performance of ML. The clash between the
existing data and the new data, in my opinion, should only happen on the level of duplication checks but in your case something else was
apparently going on. I personally would not let this case go without digging into the problem to the end as it seems to have a good learning
potential but, obviously, I cannot insist on you doing additional tests. I guess what stops you is Informatica's inability to freely manipulate
the end ML script which it generates. This is a limitation with any ETL tool. When it gets to pure Teradata issues and their tuning ETL tool often
prove to be a limiting factor.
But if you do have the time and the curiosity to stage more experiments and publish the results it would be cool.
Victor
| |
