Sacar peso en bytes de un select

[gnzsoloyo]

En esencia el costo de una consulta está determinado por la cantidad de bloques de datos necesarios para responderla (recordando que un bloque de datos en los DBMS es un segmento de 8Kb), y la cantidad de accesos a disco necesarios para recuperar los datos solicitados.

La idea es:
Tr = cantidad de tuplas de la relación
Br = cantidad de bloques que ocupa R
V(A,r) = cantidad de valores distintos del atributo A en la relación R.
Lr = Longitud de una tupla

SUPUESTO : R tiene una distribución UNIFORME.

Código SQL:

SELECT *
FROM R
WHERE A ?? 'a'
 

Donde ?? es { = , < , > , >= , <=, <>}

Costos de lectura: (CL)
a) Si Existe Indice agrupado (cluster) en A = ”a” entonces CL = Br / V(A,r)
b) Si existe Indice no agrupado (no cluster) en A = “a” entonces CL = Tr / V(A,r)
c) Si Existe Indice agrupado (cluster) en A ψ ”a” entonces CL = Br / 2 donde ψ es { < , > , <= , >= }
d) Si existe Indice no agrupado (no cluster) en A ψ “a” entonces CL = Tr / 2 donde ψ es { < , > , <= , >= }
e) Si no existe ningún índice entonces CL = Br

Ejemplo:

Código SQL:

SELECT Np
FROM proveedor
WHERE ciudad = 'Xxxx';
 

Datos:
Tr = 200 tuplas
Fb = 10 tuplas/ bloque
V(ciudad,proveedor) = 10

Si se cuenta con un índice cluster por ciudad, entonces el CL = Br / V(A,r)

Calculo de Br
Br = Tr / fb = 200 tuplas / 10 tuplas/ bloque = 20 bloques.

El costo de lectura de la selección es de 2 accesos a bloque, o sea que es recomendable crear un índice cluster por ciudad para mejorar la performance

Fuente: Apuntes de Bases de Datos II - U.Morón - Argentina
(Mi agradecimiento a los titulares de la cátedra de Bases de Datos II, de la U.M, quienes me proveyeron los apuntes durante la cursada)

Luego te paso los casos de JOIN INNER JOIN y producto cartesiano.