Methods to Maintain a Join Index | VantageCloud Lake - General Method of Maintaining a Join Index during Simple DELETE Operations - Teradata Vantage

Teradata® VantageCloud Lake

Deployment
VantageCloud
Edition
Lake
Product
Teradata Vantage
Published
January 2023
Language
English (United States)
Last Update
2024-04-03
dita:mapPath
phg1621910019905.ditamap
dita:ditavalPath
pny1626732985837.ditaval
dita:id
phg1621910019905

Example: 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:

Step Action
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 follows.

  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.