PostgreSQL ltree- vs tree module vs integer/string array o string delimited path

Question

Come forse sapete, esiste un modulo per PostgreSQL chiamato ltree. Inoltre hai la possibilità di usare il tipo Array per i numeri interi (* 1, vedi commento sotto), che in questo test mostra di funzionare effettivamente un po 'più lentamente con le sue query ricorsive, rispetto a ltree - eccetto dall'indicizzazione delle stringhe (* 2, vedi commento sotto).

Non sono sicuro della credibilità di questi risultati.

La mia più grande domanda qui riguarda in realtà il modulo ad albero relativamente sconosciuto e quasi non documentato. Descritto here (dove la documentazione può anche essere trovato !!) come:

il supporto per i tipi di dati gerarchici (una specie di alberi lessicografici), dovrebbe andare a contrib/albero, in attesa a causa della mancanza di una corretta documentation.

Dopo la lettura attraverso la documentazione Sono un po 'confuso come a se o non dovrei basare la mia grande applicazione (un CMS, dove tutto sarà memorizzato in una struttura ad albero hiearchical - non solo i contenuti, anche i file ecc., in modo che tu possa vederlo rapidamente in scala) intorno a ltree, normale percorso materializzato (Path Enumeration) con una stringa delimitata o array intero come percorso - o se il modulo "albero" relativamente sconosciuto in teoria dovrebbe essere il più veloce, più scalabile e migliore soluzione dei due.

Ho già analizzato i diversi modelli di struttura ad albero e, a causa delle prestazioni di query, scalabilità e riordino di nodi e sottostrutture sono i miei requisiti principali, sono stato in grado di escludere gli elenchi di Adjacency (il CTE ricorsivo non risolverà le prestazioni come l'albero scala enorme), insiemi/intervalli nidificati (non abbastanza veloce in alcune query, considerando i suoi svantaggi quando si gestisce l'albero), Tabelle di chiusura (terribilmente grande in scala in alberi complessi - non utile per un progetto così grande come il mio) ecc. ha deciso di andare con il percorso materializzato, che è super veloce per le operazioni di lettura, e rende facile spostare sottostrutture e nodi attorno alla ricerca. Quindi la domanda riguarda solo il meglio delle implementazioni proposte per il percorso materializzato.

Sono particolarmente curioso di sentire le tue teorie o esperienze con "albero" in PostgreSQL.

Answer 1

Per quanto ho letto, contrib/tree non è mai stato rilasciato ufficialmente, mentre ltree è stato unito al nucleo di PostgreSQL.

Capisco entrambi utilizzano la stessa idea di percorso con l'etichetta, ma albero permesso solo etichette interi, quando ltree permette etichette di testo che i permessi di ricerche full-text, pensato per tutta la lunghezza percorso è limitato (65Kb max, 2Kb preferita).