Optimización de DELETES para particiones completas en Teradata.

Hace poco veíamos la optimización de INSERTS en particiones vacías en Teradata. También se ha hablado aquí de los “FAST PATH DELETES” en los borrados incondicionales sobre tablas. Pues bien, existe una optimización que relaciona estas dos: La optimización de DELETES de particiones completas.

Para que esta optimización se produzca es necesario que la condición de borrado (WHERE) sea tal que cubra una o varias particiones completamente, según la “partitioning expression” de definición del PPI.

Además:
·El DELETE debe ser el último o único “statement” (como ya se explicó en los “FAST PATH DELETES“).
·La tabla no debe tener join o hash indexes, integridad referencial o replicación.

Esta optimización ocurre en dos fases:
1.- Se evita el uso del “TRANSIENT JOURNAL”.
2.- Se evita la lectura de todos los “datablocks” de la partición: sólo se necesita leer el primero y el último de la misma.

Hay que decir que si la condición de borrado (WHERE) comprende particiones completas y no completas, la optimización sólo ocurrirá en las completas, siendo los borrados de las filas de particiones no cubiertas completamente borrados ordinarios (transient journal, datablocks…).

Vamos a verlo con un ejemplo:

 BTEQ -- Enter your SQL request or BTEQ command:
CREATE TABLE CARLOS.PRUEBA01_PPI
   ( ID_N INTEGER NOT NULL,
     C_TXT VARCHAR(25) NULL,
     D_DATE DATE FORMAT 'yyyy-mm-dd' NOT NULL)
PRIMARY INDEX (ID_N)
PARTITION BY (
               RANGE_N(D_DATE BETWEEN DATE '2013-01-01'
                                  AND DATE '2013-12-31'
                       EACH INTERVAL '1' MONTH)
             )
;

 *** Table has been created.
 *** Total elapsed time was 1 second.

 BTEQ -- Enter your SQL request or BTEQ command:
INSERT INTO CARLOS.PRUEBA01_PPI VALUES(1,'ENERO','2013-01-01');

 *** Insert completed. One row added.
 *** Total elapsed time was 1 second.

 BTEQ -- Enter your SQL request or BTEQ command:
INSERT INTO CARLOS.PRUEBA01_PPI VALUES(2,'FEBRERO','2013-02-01');

 *** Insert completed. One row added.
 *** Total elapsed time was 1 second.

 BTEQ -- Enter your SQL request or BTEQ command:
INSERT INTO CARLOS.PRUEBA01_PPI VALUES(3,'MARZO','2013-03-01');

 *** Insert completed. One row added.
 *** Total elapsed time was 1 second.

 BTEQ -- Enter your SQL request or BTEQ command:
INSERT INTO CARLOS.PRUEBA01_PPI VALUES(4,'ABRIL','2013-04-01');

 *** Insert completed. One row added.
 *** Total elapsed time was 1 second.

 BTEQ -- Enter your SQL request or BTEQ command:
INSERT INTO CARLOS.PRUEBA01_PPI VALUES(5,'MAYO','2013-05-01');

 *** Insert completed. One row added.
 *** Total elapsed time was 1 second.

 BTEQ -- Enter your SQL request or BTEQ command:
INSERT INTO CARLOS.PRUEBA01_PPI VALUES(6,'JUNIO','2013-06-01');

 *** Insert completed. One row added.
 *** Total elapsed time was 1 second.

 BTEQ -- Enter your SQL request or BTEQ command:
SELECT * FROM CARLOS.PRUEBA01_PPI ORDER BY 1;

 *** Query completed. 6 rows found. 3 columns returned.
 *** Total elapsed time was 1 second.

       ID_N  C_TXT                          D_DATE
-----------  -------------------------  ----------
          1  ENERO                      2013-01-01
          2  FEBRERO                    2013-02-01
          3  MARZO                      2013-03-01
          4  ABRIL                      2013-04-01
          5  MAYO                       2013-05-01
          6  JUNIO                      2013-06-01

 BTEQ -- Enter your SQL request or BTEQ command:
EXPLAIN
DELETE
  FROM CARLOS.PRUEBA01_PPI
 WHERE D_DATE BETWEEN '2013-02-15' AND '2013-04-15'
;

 *** Help information returned. 16 rows.
 *** Total elapsed time was 1 second.

Explanation
--------------------------------------------------------------------------------
  1) First, we lock a distinct CARLOS."pseudo table" for write on a
     RowHash to prevent global deadlock for CARLOS.PRUEBA01_PPI.
  2) Next, we lock CARLOS.PRUEBA01_PPI for write.
  3) We do an all-AMPs DELETE from 2 partitions of CARLOS.PRUEBA01_PPI
     with a condition of ("(CARLOS.PRUEBA01_PPI.D_DATE >= DATE
     '2013-02-15') AND (CARLOS.PRUEBA01_PPI.D_DATE <= DATE
     '2013-04-15')").
  4) We do an all-AMPs DELETE of a single partition from
     CARLOS.PRUEBA01_PPI with a condition of (
     "(CARLOS.PRUEBA01_PPI.D_DATE >= DATE '2013-02-15') AND
     (CARLOS.PRUEBA01_PPI.D_DATE <= DATE '2013-04-15')").  The size is
     estimated with no confidence to be 1 row.  The estimated time for
     this step is 0.01 seconds.
  5) 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.

 BTEQ -- Enter your SQL request or BTEQ command:

La expresión del EXPLAIN “We do an all-AMPs DELETE of a single partition” indica que la optimización tiene lugar al borrar una partición completa (MARZO), mientras que la expresión “We do an all-AMPs DELETE from 2 partitions” indica que los borrados en las otras dos particiones (FEBRERO, ABRIL), que no se cubrían completamente, son borrados ordinarios, no optimizados.

Saludos.

Carlos.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: