pg_re2 porta le regex RE2 in Postgres, e risolve un problema di coerenza con ClickHouse

ClickHouse ha rilasciato pg_re2, una extension Postgres che espone le regular expression basate su RE2, la stessa libreria che ClickHouse usa per string search, replacement, extraction e splitting. Si installa da PGXN o GitHub, ed è già presente su ClickHouse Managed Postgres. Le motivazioni dichiarate sono due: velocità e compatibilità. La seconda è la più interessante.

La velocità

I due engine partono da algoritmi diversi. Le regex POSIX di Postgres si basano su backtracking e restituiscono il match più lungo; RE2 usa automi a stati finiti, il che gli dà garanzie più forti sui tempi di esecuzione — è l’argomento con cui Russ Cox presentò RE2 nel 2010.

Il benchmark incluso nel progetto, eseguito su un’istanza AWS m6g.2xlarge con PostgreSQL 18, riporta RE2 in vantaggio su tutti i test, con speedup tra 1,8x e 8,6x. Il guadagno più alto è su extract_all (7,2–8,6x), ma gli autori stessi lo definiscono un confronto poco equo, perché restituisce array direttamente mentre regexp_matches(..., 'g') paga l’overhead di una set-returning function.

La versione 0.4.0 aggiunge l’operatore @~ e il supporto a indici btree e GIN. Qui i guadagni sono più modesti, tra 1,1x e 1,8x. La nota utile: l’opclass gin_re2_ops raccoglie i trigram byte-equivalent richiesti da RE2 anche attraverso la punteggiatura, quindi pattern come error_code=42[0-9] usano l’indice dove Postgres con pg_trgm ricade su un full table scan. Sui pattern a parola piena, però, pg_trgm può vincere grazie a un consistent check più economico.

Il problema vero: due dialetti, un piano di query

Chi usa pg_clickhouse per interrogare tabelle foreign ha un problema meno visibile. Dalla versione 0.2.0 l’extension fa pushdown di alcuni operatori verso ClickHouse. Ottimo, finché la regex non ha una sintassi che i due engine interpretano diversamente.

L’esempio che gli autori portano è istruttivo. WHERE by ~ 'Quake\b' viene spinta a ClickHouse e restituisce due righe; la stessa espressione nella select list gira in Postgres e restituisce false per entrambe. Motivo: in ClickHouse \b è un word boundary, in Postgres è un carattere di backspace. Non è un caso isolato: \B, \m, \y, \Z, le backreference, i lookahead e le classi Unicode si comportano diversamente o non esistono da una parte o dall’altra, e anche i flag divergono in modo sostanziale.

La risposta è pg_clickhouse 0.3.0, che aggiunge il pushdown delle funzioni pg_re2. Usando re2match() al posto di ~ il risultato è lo stesso che la query venga eseguita in Postgres o spinta a ClickHouse, perché sotto c’è la stessa libreria. Smetti di dover sapere se il pushdown è avvenuto.

In sintesi

• RE2 batte le regex native di Postgres in tutti i test del benchmark (1,8–8,6x su table scan, 1,1–1,8x su indice).
• Il beneficio maggiore è la coerenza semantica: \b e altri costrutti significano cose diverse nei due engine, e il pushdown lo rende un bug silenzioso.
• Se lavori con pg_clickhouse, testa le regex con attenzione su flag, character class e sequenze backslash — oppure passa alle funzioni pg_re2.

Fonte: Introducing pg_re2, fast, RE2-powered regular expressions in Postgres