Eu tenho experimentado índices tsvector para pesquisa de texto completo e vejo que é uma prática comum gerar um vetor de armazenamento em uma coluna do tipo tsvector. Estamos no Postgres 11.4, mas já vi essa mesma prática usada como exemplo para colunas geradas pelo PG 12. (Mais simples do que usar um gatilho para o mesmo propósito.)
Minha pergunta é, qual é o benefício? Eu tentei um índice GIN de expressão no tsvector de um campo de texto e um índice GIN no tsvector armazenado. Com cerca de 8 milhões de linhas localmente, não consegui medir nenhuma diferença de velocidade significativa. Dado que armazenar o vetor como uma coluna e um índice ocupa mais espaço, estou curioso para saber se existem casos óbvios em que o custo extra é justificado. Por exemplo, quando você tem muito mais papéis.
Nota: Estamos armazenando o texto no banco de dados, portanto, esta não é uma daquelas configurações em que você indexa uma página/documento/etc externo sem absorver o texto de origem no banco de dados.
Se você usar a pesquisa de proximidade (como "phraseto_tsquery", por exemplo), com um índice funcional, ele terá que analisar novamente cada documento candidato a correspondência com um tsvector e verificar a sequência e o espaçamento corretos das palavras. Isso pode ser bastante lento, especialmente se o número de candidatos for muito maior do que o número de resultados finais. Se o tsvector estiver armazenado, ele pode apenas lê-lo e não analisar novamente o documento, isso é muito mais rápido. Acho que outros recursos avançados como "ts_headline" podem estar na mesma situação - mas não os testei.
Mesmo se você usar apenas "@@",
acho que, se o bitmap do número de resultados não couber em "work_mem", ele também precisará analisar novamente os documentos para verificar novamente os blocos correspondentes de candidatos que "transbordaram" . É claro que, nesse caso, aumentar "work_mem" provavelmente seria uma opção melhor do que adicionar uma coluna.Por que vale a pena, se você usar RUM em vez de GIN, ele resolverá o problema com ophraseto_tsquery nos índices funcionais.
Apenas curiosamente, eu tinha um índice GIN criado em uma coluna, com alguns valores grandes (fazendo extração de texto do documento, vários parágrafos, se não muitas páginas de texto por linha).
As consultas estavam demorando mais de 60 segundos dependendo da consulta, a mudança para uma coluna de vetor pré-computada + índice melhorou significativamente essas consultas , até 2-3s em "ruins".
Basicamente, apenas segui as etapas de https://www.postgresql.org/docs/14/textsearch-tables.html "12.2.2. Criando índices", onde você começa com um índice funcional e, no final, faz a transição para o " coluna + índice".
Portanto, eu recomendo a qualquer pessoa que esteja fazendo essa pergunta que faça um benchmark de sua configuração.