General and Optimized Methods to Maintain a Join Index | Teradata Vantage - 17.10 - General Method of Maintaining a Join Index During Simple DELETE Operations - Advanced SQL Engine - Teradata Database

Teradata Vantage™ - SQL Request and Transaction Processing

Product
Advanced SQL Engine
Teradata Database
Release Number
17.10
Release Date
July 2021
Content Type
Programming Reference
User Guide
Publication ID
B035-1142-171K
Language
English (United States)

Example of a General Method for Maintaining a Join Index During Simple DELETE Operations

The following is an example of a general case method for maintaining a join index during a simple DELETE request.

Note the following items in the EXPLAIN output:

This step … Does this …
             5 Reproduces the affected portion of the join index rows.
             6.1 Deletes the corresponding rows from the join index.
             8 Inserts new nonmatching outer join rows into the join index.
     EXPLAIN
     DELETE FROM ordertbl
     WHERE o_custkey = 1001;

Part of the EXPLAIN output is shown below.

  5) We do an all-AMPs JOIN step in TD_MAP1 from DB1.lineitem by way
     of a RowHash match scan with no residual conditions, which is
     joined to 84 partitions of DB1.Ordertbl by way of a RowHash match
     scan with a condition of ("DB1.ordertbl.o_custkey = 1001").
     DB1.lineitem and DB1.Ordertbl are joined using a sliding-window
     merge join, with a join condition of ("DB1.lineitem.l_orderkey =
     DB1.Ordertbl.o_orderkey").  The result goes into Spool 1
     (all_amps), which is built locally on the AMPs.  Then we do a SORT
     to order Spool 1 by the hash code of (DB1.Ordertbl.o_orderdate).
     The size of Spool 1 is estimated with low confidence to be 2 rows
     (106 bytes).  The estimated time for this step is 0.17 seconds.
  6) We execute the following steps in parallel.
       1) We do an all-AMPs MERGE DELETE to DB1.ORDERJOINLINE from
          Spool 1.  The size is estimated with low confidence to be 2
          rows.  The estimated time for this step is 4.60 seconds.
       2) We do an all-AMPs DELETE step in TD_MAP1 from 84 partitions
          of DB1.ordertbl with a condition of (
          "DB1.ordertbl.o_custkey = 1001").  The size is estimated
          with low confidence to be 1 row.  The estimated time for this
          step is 0.05 seconds.
  7) We do an all-AMPs RETRIEVE step in TD_Map1 from Spool 1 (Last Use)
     by way of an all-rows scan into Spool 2 (all_amps), which is
     redistributed by the hash code of (DB1.lineitem.l_orderkey) to
     all AMPs in TD_Map1.  Then we do a SORT to order Spool 2 by join
     index.  The size of Spool 2 is estimated with low confidence to be
     2 rows (106 bytes).  The estimated time for this step is 0.16
     seconds.
  8) We do an all-AMPs MERGE step in TD_MAP1 into DB1.ORDERJOINLINE
     from Spool 2 (Last Use).  The size is estimated with low
     confidence to be 2 rows.  The estimated time for this step is 1.34
     seconds.
  9) We spoil the parser's dictionary cache for the table.
 10) Finally, we send out an END TRANSACTION step to all AMPs involved
     in processing the request.
  -> No rows are returned to the user as the result of statement 1.