Caso de Estudio Relación PROFESOR(id, nom, deptid) páginas, 1000 filas (5 filas/página) - 50 deps 20 profesores/dep en promedio - Índices: Clustered B+ sobre deptid Hash sobre id -Peso de id: 1 (de hecho id es la CP) -nom no es CA
Caso de Estudio Relación CUR_PROF(profid, crscod, semestre) páginas, filas (10 filas/página) - La relación abarca 4 semestres 2500 filas/semestre - Índices: Clustered B+ sobre semestre Hash sobre profid - Peso de profid: 10 (10 filas por profesor en CUR_PROF) CF hacia PROFESOR
Caso de Estudio Sea la consulta: SELECT DISTINCT P.id, P.nom FROM profesor AS P, cur_prof AS C WHERE P.id = C.profid AND C.semestre = 'F2015' AND P.deptid = 'CS'; Condición de join Selecciones Proyección Nota: En los ejemplos que siguen se hace caso omiso del ordenamiento que usualmente conlleva una operación DISTINCT.
Caso de Estudio Sean las expresiones algebraicas equivalentes a la consulta anterior: a) id,nom ( deptid = ‘CS’ semestre = ‘F2015’ (PROFESOR ⋈ id = profid CUR_PROF)) b) id,nom ( deptid = ‘CS’ (PROFESOR) ⋈ id = profid semestre = ‘F2015’ (CUR_PROF)) c) id,nom ( semestre = ‘F2015’ ( deptid = ‘CS’ (PROFESOR) ⋈ id = profid CUR_PROF)) d) id,nom ( deptid = ‘CS’ (PROFESOR ⋈ id = profid semestre = ‘F2015’ (CUR_PROF)))
PROFESORCUR_PROF ⋈ id = profid deptid = ‘CS’ semestre = ‘F2015’ id,nom PROFESOR CUR_PROF ⋈ id = profid deptid = ‘CS’ id,nom semestre = ‘F2015’ a) b) Árboles para los planes de ejecución
PROFESORCUR_PROF ⋈ id = profid deptid = ‘CS’ id,nom semestre = ‘F2015’ PROFESORCUR_PROF ⋈ id = profid deptid = ‘CS’ id,nom semestre = ‘F2015’ c) d) Árboles para los planes de ejecución
Caso de Estudio a) Supóngase una memoria (M) de 52 páginas. Costo del join con block nested: F PROFESOR + F CUR_PROF * F PROFESOR /(M-2) = * 200/(52-2) = 4200 (páginas) El resultado del join serán filas, aproximadamente 3000 páginas (ya que cada fila de PROFESOR es el doble del tamaño de cada fila de CUR_PROF)
Caso de Estudio El costo de escribir el resultado de la selección y de la proyección, proceso que se hace conjuntamente (pipelining) con el join, es: ( x 3000) donde es un factor* entre 0 y 1 que indica el total de páginas resultantes. Este costo es el mismo para todos los planes. * Factor de reducción debido a la restricción y proyección finales.
Caso de Estudio b) Con block nested: Primero se hacen las selecciones: -Dado que hay 1000 profesores en 50 departamentos, el tamaño de deptid = ‘CS’ (PROFESOR) es 20 filas, o sea, 4 páginas -Como el peso de semestre en CUR_PROF es 2500, entonces el tamaño de semestre = ‘F2015’ (CUR_PROF) es 250 páginas
Caso de Estudio -Costo de las selecciones: como en ambas relaciones hay índice clustered B+ sobre deptid y semestre respectivamente, el costo total de las selecciones es: = 258 Acceso índice de PROFESOR Acceso índice de CUR_PROF Páginas resultantes de PROFESOR Páginas resultantes de CUR_PROF
Caso de Estudio Como la relación deptid = ‘CS’ (PROFESOR) es tan pequeña, se puede mantener en memoria y a medida que se va generando la la relación semestre = ‘F2015’ (CUR_PROF) se va haciendo el join; por lo tanto, no se requieren accesos adicionales: Costo total: 258 (páginas)
Caso de Estudio c) Se hace la selección sobre PROFESOR usando el índice clustered sobre deptid, esto genera una relación de 4 páginas (20 filas) que cabe en memoria como en el caso b), el costo es: = 6 Acceso índice de PROFESOR Páginas resultantes de PROFESOR
Caso de Estudio Para aprovechar el índice unclustered sobre profid en CUR_PROF se usará en este caso un index nested. La selección anterior genera 20 filas; cada una se espera haga join con 10 filas en promedio de CUR_PROF. Por lo tanto, se requiere: accesos: costo de búsqueda de cada profesor en el índice sobre profid en CUR_PROF - 10 accesos adicionales por cada fila de PROFESOR dado que el índice es unclustered. O sea:
Caso de Estudio Costo join: (1.2) * (20) = 24 (10) * (20) = Costo total: = 230 (páginas) Costo de usar el índice Páginas leídas de CUR_PROF
Caso de Estudio d) Primero la selección sobre CUR_PROF: El costo de semestre = ‘F2015’ (CUR_PROF) es: = 252 páginas como en el caso b) y desde ya (y solo con esta selección inicial) pierde con el caso c)… Acceso índice de CUR_PROF Páginas resultantes de CUR_PROF
Caso de Estudio Conclusión: En este caso la mejor opción fue la c) pero habría que evaluar otras alternativas (sort merge join, hash join, etc.) en general en cada una de las opciones…