Si dovrebbe memorizzare un tsvector search_data nella stessa tabella o tabella esterna?

Question

Sto implementando la ricerca full-text in postgres.

Vorrei cercare tutti i messaggi nel mio sistema. L'indice fulltext post è una fusione del titolo del post e del corpo del post.

mi hanno due modi per raggiungere questo:

1. crea una colonna tsvector nella tabella messaggi, attivare un aggiornamento ad esso.
2. creare una seconda tabella (posts_search) con una colonna post_id e tsvector contenente i dati dell'indice.
3. creare un semplice indice di gin ... (fuori questione, causa il mio vero problema del mondo ha bisogno di dati in più tabelle per l'indice)

ciò che sta per eseguire meglio, considerando che ho a volte bisogno di filtrare giù la ricerca per altri attributi nella tabella (come deleted_at is null e così via).

E 'un approccio migliore per mantenere la colonna tsvector nella stessa tabella come i dati (effetto collaterale select * ora succhia) o una tabella separata (effetto collaterale, unire richiesto, filtraggio indice è complicato)?

Answer 1

Nei miei esperimenti, la dimensione tipica della colonna tsvector è circa 1% della dimensione del campo di testo che questo tsvector è stato calcolato utilizzando to_tsvector().

Con questo in mente, la memorizzazione della colonna di tsvector in un'altra tabella dovrebbe fornire vantaggi in termini di prestazioni. Ad esempio, anche se non si utilizza SELECT * (e non si dovrebbe, davvero), qualsiasi seqscan nella tabella singola originale dovrà ancora caricare pagine che contengono testo originale. Se si scarica il campo tsvector per separare la tabella, il caricamento della pagina sarà più veloce di 100x.

In altre parole, vorrei favorire la seconda soluzione di offload del campo tsvector per separare la tabella. Oppure, in alternativa, scaricare i post (testo originale) più in profondità nella gerarchia della tabella (ma suppongo che sia quasi la stessa cosa).

Nota che per la ricerca a testo integrale, il testo originale non è necessario. Non vuoi nemmeno archiviarlo nel database o archiviarlo in un formato altamente compresso (e non necessariamente facilmente accessibile dalle routine SQL). Funzionerebbe finché qualcosa può creare tsvector in base al testo originale o aggiornarlo quando cambia.