How is it possible that a table could be created without Primary Index (Teradata 13)?

How is data distributed among the AMPs? In TD 13 there is an option to create tables with no primary index. On this one, we broke all the rules, and the developers had a lot of fun doing it! As you kn ow, on TD a table always has a PI, always has data distribution driven by the ha sh vlaue of the PI. Once rows arrive at their AMP, they are stored in order by h ash value...and that is true of every table on TD. In the case of No Primary Ind ex Tables (NoPI), they are not hash distributed, and they are not hash ordered. The goal of NoPI tables is to have a table that is very efficient to acquire dat a into. Like ELT for batch or work tables. These table are not going to be posit ioned properly for joins or primary index access, they're intended to just be pl aces to temporarily land and store data -- until you do the next processing step that generally would have to scan the table and read every row anyway. This wil l significantly improve the overall process. For example, you define a NoPI tabl e and load the data with a FastLoad. Instead of doing all the row redistribution , sorting, etc, we are going to take each block that FastLoads into the table an d randomly pick an AMP that is going to get that block of data. Then, we'll takd that data block and insert it at the end of the table, that's it. Getting the d ata into the work tables is going to be a lot more efficient. 30+% improvement i n acquiring data in FDL in phase one. Insert/select into that table will be a li ttle different because the data is not coming from outside so data it will flow into the table based on the AMP where it was created so final result of the quer y won t be redistributed, we ll store the data locally. At that point, inserting dat a into the table by row hash goes away and the rows just go to the end of the ta ble (on that AMP). This table is only meant to be scanned and used for the next operation, not a specific select operation. NoPI tables will reduce skew in the batch load operation and you won't have to fret or think about which column(s) w ould make the best index. Secondary indexes are allowed on NoPI tables and secon dary index access paths for SQL statements will work the same on a NoPI table as they do for a PI table. That being the case, we all really know that every row in TD has a unique identifier, the rowid. For the NoPI tables, the system will g enerate a rowid based on the AMP where the row is being stored. No, you can't ch oose what you want it to be, and no, you can't use it as though it were a real P rimary Index.