The following table describes Teradata TPump restrictions and limitations on operational features and functions.
|Maximum row size||The maximum row size for a Teradata TPump job, data plus indicators, is approximately 64,000 bytes. This limit is a function of the row size limit of the database.|
|Expressions||Evaluated from left to right, using the database order of preference, but can be overridden by parentheses.|
|IMPORT commands||Limit of 100 IMPORT commands within a single TPump load task.|
|Date specification||For dates before 1900 or after 1999, the year portion of the date must be represented by four numerals (yyyy). The default of two numerals (yy) to represent the year is interpreted to be the 20th century, and must be overridden to avoid spurious year information. If the table column defined as type DATE does not have the proper format, the dates may not process properly. The correct date format must be specified at the time of table creation, for example:
CREATE TABLE tab (ADATE DATE*); DEFINE a (char(10)) INSERT tab (ADATE = :a(DATE, FORMAT 'yyyy-mm-dd'));
|Access logging||Unlike the MultiLoad and FastLoad utilities, access logging can cause a severe performance penalty in Teradata TPump. This is because Teradata TPump uses normal SQL operations rather than a proprietary protocol, and if all successful table updates are logged, a log entry is made for each operation. The primary index of the access logging table may then create the possibility of row hash conflicts.|
|Primary Indexes and Partitioning Column Sets||Specify values for the partitioning column set when performing Teradata TPump deletes and updates to avoid lock contention problems that can degrade performance. Avoid updating primary index and partitioning columns with Teradata TPump to minimize performance degradation.|