Índices GIN de Postgresql: ejemplo de implementación

66.4.1. Técnica de actualización rápida GIN

66.4.2. Algoritmo de coincidencia parcial

Internamente, un índice GIN contiene un índice de árbol B construido sobre keysdonde cada key es un elemento de uno o más elementos indexados (un miembro de un arraypor ejemplo) y donde cada tupla en una hoja contiene un puntero a un árbol B de punteros de montón (un “árbol de publicación”), o una simple lista de punteros de montón (un “lista de publicaciones”) cuando la lista es lo suficientemente pequeña como para caber en una sola tupla de índice junto con el key valor. La Figura 66.1 ilustra estos componentes de un índice GIN.

A partir de PostgreSQL 9.1, null key los valores se pueden incluir en el índice. Además, los valores nulos de marcador de posición se incluyen en el índice para elementos indexados que son null o no contienen keys de acuerdo a extractValue. Esto permite realizar búsquedas que deberían encontrar elementos vacíos.

Los índices GIN de varias columnas se implementan mediante la creación de un solo árbol B sobre valores compuestos (número de columna, key valor). los key los valores para diferentes columnas pueden ser de diferentes tipos.

Figura 66.1. Interiores GIN

66.4.1. Técnica de actualización rápida GIN

La actualización de un índice GIN tiende a ser lenta debido a la naturaleza intrínseca de los índices invertidos: insertar o actualizar una fila del montón puede generar muchas inserciones en el índice (una para cada key extraído del ítem indexado). A partir de PostgreSQL 8.4, GIN es capaz de posponer gran parte de este trabajo mediante la inserción de nuevas tuplas en una lista temporal sin clasificar de entradas pendientes. Cuando la mesa es aspirada o autoanalizada, o cuando gin_clean_pending_list se llama a la función, o si la lista pendiente se vuelve más grande que gin_pending_list_limit, las entradas se mueven a la estructura de datos GIN principal usando las mismas técnicas de inserción masiva que se usaron durante la creación del índice inicial. Esto mejora en gran medida la velocidad de actualización del índice GIN, incluso contando la sobrecarga de vacío adicional. Además, el trabajo general se puede realizar mediante un proceso en segundo plano en lugar de un procesamiento de consultas en primer plano.

La principal desventaja de este enfoque es que las búsquedas deben escanear la lista de entradas pendientes además de buscar en el índice regular, por lo que una gran lista de entradas pendientes ralentizará significativamente las búsquedas. Otra desventaja es que, si bien la mayoría de las actualizaciones son rápidas, una actualización que hace que la lista de pendientes se vuelva “demasiado grande” incurrirá en un ciclo de limpieza inmediato y, por lo tanto, será mucho más lento que otras actualizaciones. El uso adecuado del autovacío puede minimizar ambos problemas.

Si el tiempo de respuesta consistente es más importante que la velocidad de actualización, el uso de entradas pendientes se puede deshabilitar apagando el fastupdate parámetro de almacenamiento para un índice GIN. Ver CREAR ÍNDICE para más detalles.

66.4.2. Algoritmo de coincidencia parcial

GIN puede apoyar “coincidencia parcial” consultas, en las que la consulta no determina una coincidencia exacta para uno o más keyspero las posibles coincidencias caen dentro de un rango razonablemente estrecho de key valores (dentro del key orden de clasificación determinado por el compare método de apoyo). los extractQuery método, en lugar de devolver un key valor para que coincida exactamente, devuelve un key valor que es el límite inferior del rango que se va a buscar, y establece el pmatch bandera true. los key luego se escanea el rango usando el comparePartial método. comparePartial debe devolver cero para un índice coincidente keymenor que cero para una no coincidencia que todavía está dentro del rango de búsqueda, o mayor que cero si el índice key está más allá del rango que podría coincidir.