Recabamos en todo internet para traerte la solución para tu dilema, en caso de alguna difcultad deja tu comentario y responderemos con mucho gusto, porque estamos para ayudarte.
Solución:
Utilice el integrado de PostgreSQL uuid tipo de datos y cree un índice b-tree regular en él.
No hay necesidad de hacer nada especial. Esto dará como resultado un índice óptimo y también almacenará la uuid campo en una forma tan compacta como es práctica actualmente.
(Los índices hash en PostgreSQL anteriores a la versión 10 no eran a prueba de fallas y en realidad eran una reliquia histórica que tendía a funcionar no mejor que un árbol B de todos modos. Evítelos. En PostgreSQL 10 se han hecho a prueba de fallas y tenían algunos Se realizaron mejoras de rendimiento, por lo que es posible que desee considerarlas).
Si por alguna razón no puede usar el uuid tipo, generalmente crearía un árbol b en la representación de texto o, preferiblemente, un bytea representación del uuid.
¿Índice BRIN? Si utiliza UUID basados en el tiempo (versión 1), se generan para que su valor aumente. En cuyo caso BRIN es adecuado.
https://www.postgresql.org/docs/9.5/brin-intro.html:
BRIN significa Block Range Index. BRIN está diseñado para manejar tablas muy grandes en las que ciertas columnas tienen una correlación natural con su ubicación física dentro de la mesa. UN el rango de bloques es un grupo de páginas que son físicamente adyacentes en la tabla; para cada rango de bloques, el índice almacena información resumida. Por ejemplo, una tabla que almacena los pedidos de venta de una tienda puede tener una columna de fecha en la que se realizó cada pedido y, la mayoría de las veces, las entradas de pedidos anteriores también aparecerán antes en la tabla; una tabla que almacena una columna de código postal puede tener todos los códigos de una ciudad agrupados de forma natural.
Los índices BRIN pueden satisfacer consultas a través de escaneos regulares de índices de mapas de bits y devolverán todas las tuplas en todas las páginas dentro de cada rango si la información de resumen almacenada por el índice es consistente con las condiciones de la consulta. El ejecutor de consultas está a cargo de volver a verificar estas tuplas y descartar aquellas que no coinciden con las condiciones de la consulta; en otras palabras, estos índices tienen pérdidas. Debido a que un índice BRIN es muy pequeño, escanear el índice agrega poca sobrecarga en comparación con un escaneo secuencial, pero puede evitar escanear grandes partes de la tabla que se sabe que no contienen tuplas coincidentes.
Los datos específicos que almacenará un índice BRIN, así como las consultas específicas que el índice podrá satisfacer, dependen de la clase de operador seleccionada para cada columna del índice. Los tipos de datos que tienen un orden de clasificación lineal pueden tener clases de operadores que almacenan el valor mínimo y máximo dentro de cada rango de bloque, por ejemplo; los tipos geométricos pueden almacenar el cuadro delimitador para todos los objetos en el rango de bloques.
El tamaño del rango de bloques se determina en el momento de la creación del índice mediante el parámetro de almacenamiento pages_per_range. El número de entradas de índice será igual al tamaño de la relación en páginas dividido por el valor seleccionado para páginas_por_rango. Por lo tanto, cuanto más pequeño es el número, más grande se vuelve el índice (debido a la necesidad de almacenar más entradas de índice), pero al mismo tiempo, los datos de resumen almacenados pueden ser más precisos y se pueden omitir más bloques de datos durante una exploración de índice.
Perfecto para datos grandes y “principalmente” ordenados.
Vea esta publicación para algunos puntos de referencia:
https://www.percona.com/blog/2019/07/16/brin-index-for-postgresql-dont-forget-the-benefits/
Generaron una tabla de 1,3 GB de datos ordenados naturalmente (marcas de tiempo incrementadas). Luego generaron un índice BRIN (con pages_per_range = 32) y un índice B-Tree en esta base de datos. Luego compararon el tiempo de ejecución de SELECT y el tamaño de los índices. Lo que obtuvieron:
Árbol B:
Tiempo de Planificación: 22.225 ms Tiempo de Ejecución: 2.657ms
publico | testtab_date_idx | índice | postgres | ficha de prueba | 171 megabytes
SALIR:
Tiempo de planificación: 0,272 ms Tiempo de ejecución: 87.703ms
publico | testtab_date_brin_idx | índice | postgres | ficha de prueba | 64 KB
mientras tanto sin índice sería:
Tiempo de planificación: 0,296 ms Tiempo de ejecución: 1766.454ms
Sólo para dar una idea de las órdenes.
Lo que es importante discutir además es la complejidad de la actualización del índice después de INSERTAR de los dos. Mientras que para BRIN es O(1), ya que escribe secuencialmente en el siguiente espacio libre en la memoria y, en consecuencia, crea nuevas entradas BRIN, sin embargo, para B-Tree, como bien sabemos, es O(logN) (B-Trees) ( más alto el árbol más tiempo toma).
Faltan índices hash en acción en PostgreSQL. PostgreSQL sabe que necesita índices hash, y que su código para los índices hash es antiguo y está mohoso, pero no lo eliminan porque están esperando que alguien venga y revise la indexación hash. Ver este hilo:
http://www.postgresql.org/message-id/[email protected]
Si tienes alguna cuestión y capacidad de innovar nuestro escrito eres capaz de añadir una nota y con placer lo observaremos.