El desarrollador Hubert Lubaczewski (depesz) analiza sobre datos reales —1,6 millones de planes de consultas extraídos de explain.depesz.com, 33 GB en total— el rendimiento de dos extensiones recientes de PostgreSQL pensadas para acelerar búsquedas con expresiones regulares: pg_tre y pg_re2, comparándolas con el método tradicional (sequential scan) y con el índice trigrama de la extensión pg_trgm incluida en el motor.
La prueba de partida, buscar la cadena «sususu» en los planes, muestra el comportamiento por defecto: el escaneo paralelo tarda unos 41 segundos. Con pg_trgm y un índice GIN de trigramas (1.667 MB), esa misma búsqueda baja a 1,6 segundos; pg_tre queda en unos 2,3 segundos tras construir un índice de 21 GB que tarda más de 7 horas en generarse.
El autor recuerda que pg_trgm sigue siendo la opción recomendada para subcadenas exactas o LIKE y que la verdadera aportación de pg_tre es el soporte nativo de coincidencia aproximada con distancia Levenshtein: una consulta como word %~~ tre_pattern('postgresql', 1) devuelve 16 variantes ortográficas (autopostgresqlbackup, rpostgresql, postgresxl, etc.). El artículo propone combinar pg_tre para extraer términos «parecidos» y pg_trgm para localizarlos dentro de los planes. La comparativa se queda a medias: la sección dedicada a pg_re2 queda cortada en el texto publicado.