|
Archives of the TeradataForumMessage Posted: Thu, 07 Apr 2016 @ 08:16:23 GMT
Hi Roopalini, A lot of this will come down to the command used to insert rows into that final table. If it is 'INSERT/SELECT' then you ** cannot ** run multiple such commands against the same table concurrently. Such a command will place a table-level, all AMP write lock on the target table. And only one such command can run at any point in time. If two sessions are attempting to run such commands concurrently then one will block behind the other. No additional work needs to be done by the application, the DBMS will handle this. If it is an 'INSERT VALUES' command then multiple such commands can run concurrently IF they target different row hash values (for the PI). Again, if they happen to use the same row hash then one will block behind the other. But for 'INSERT VALUES' then that will be a fraction of a second. - Technically this is only an issue if it is the same row hash and same partition (if the table has PPI). I agree that a GTT is not going to help you, it simply delays the problem. I'm not sure but I think a NOPI table may actually make things worse, because typically all rows on a single AMP will have the same 'row hash'. Not sure how this works in practise. Cheers, Dave Ward Analytics Ltd - Information in motion (www.ward-analytics.com)
| ||||||||||||||||||||||||||||||||||||||||||||||||
https: | ||||||||||||||||||||||||||||||||||||||||||||||||
| ||||||||||||||||||||||||||||||||||||||||||||||||
Copyright 2016 - All Rights Reserved | ||||||||||||||||||||||||||||||||||||||||||||||||
Last Modified: 24 Jul 2020 | ||||||||||||||||||||||||||||||||||||||||||||||||