A veces una base de datos bien pensada nos viene a mostrar que en realidad no la pensamos bien.<\/p>\n
S\u00edntomas de estas diferencias entre lo planeado y la realidad, es el uso efectivo que se le d\u00e1 a los \u00edndices que creamos en las tablas. Quiero decir, si creemos que al crear un \u00edndice estamos ayudando al optimizador a realizar la tarea, pero en realidad el optimizador elije otro camino para realizarla.<\/p>\n
Esto puede suceder en \u00edndices de tablas peque\u00f1as (donde un secuencial scan es m\u00e1s barato que buscar primero en el \u00edndice) o en queries donde a la tabla se entra por otro criterio, anulando la columna indizada.<\/p>\n
Ahora bien, tener \u00edndices que no usamos puede ser malo: todo insert o delete ser\u00e1 penalizado por el hecho de tener \u00edndices, y si adem\u00e1s hacemos updates sobre el campo indizado…<\/p>\n
Planteado el problema, el administrador prevenido tiene tambi\u00e9n una soluci\u00f3n: medir el uso de los \u00edndices de las tablas.<\/p>\n
El siguiente query presenta los \u00edndices (mayores a 1mb) que est\u00e9n en nuestra base de datos, orden\u00e1ndolos por n\u00famero de uso creciente, por lo que podremos ver f\u00e1cilmente si hay \u00edndices con valores en 0.<\/p>\n
\r\n\r\n-- query para ver el uso de indices\r\n\r\nselect\r\n s.schemaname as sch,\r\n s.relname as rel,\r\n s.indexrelname as idx,\r\n s.idx_scan as scans,\r\n pg_size_pretty(pg_relation_size(s.relid)) as ts,\r\n pg_size_pretty(pg_relation_size(s.indexrelid)) as "is"\r\nfrom\r\n pg_stat_user_indexes s\r\n join pg_index i on i.indexrelid=s.indexrelid\r\n left join pg_constraint c on i.indrelid=c.conrelid\r\n and array_to_string(i.indkey, ' ') = array_to_string(c.conkey, ' ')\r\nwhere\r\n i.indisunique is false and\r\n pg_relation_size(s.relid) > 1000000 and\r\n s.idx_scan < 100000 and c.confrelid is null\r\norder by\r\n s.idx_scan asc, pg_relation_size(s.relid) desc\r\n-- limit 5\r\n\r\n<\/pre>\n","protected":false},"excerpt":{"rendered":"