capacidade e desempenho de tags implementadas como matriz x texto x texto completo

Você pode obter a funcionalidade de pesquisa com arrays usando as ANY/SOMEfunções or generate_subscripts. No entanto, a documentação do PostgreSQL observa o seguinte:

Dica : Arrays não são conjuntos; a busca por elementos de array específicos pode ser um sinal de mau design do banco de dados. Considere o uso de uma tabela separada com uma linha para cada item que seria um elemento de matriz. Isso será mais fácil de pesquisar e provavelmente será dimensionado melhor para um grande número de elementos.

Portanto, parece que você está no caminho certo, porque está correto sobre não perder desempenho (provavelmente você o ganharia) e os outros métodos permitem maior flexibilidade. As próprias tags tratam de correspondências exatas, mas a maioria dos sites também tem uma maneira de pesquisar tags (por exemplo, este mesmo site ).

Se você implementar o armazenamento de tags como texto completo , isso não impedirá a correspondência, incluindo regex, com expressões mais simples, como LIKE/ILIKE. Um cenário comum é armazenar documentos (os pedaços de texto que estão sendo pesquisados) como textou varying charactere armazenar o tsvectortipo necessário para pesquisa de texto completo em uma coluna separada. Consulte a documentação do PostgreSQL para saber mais sobre como criar um índice de texto completo.

Os prós e contras devem então ser evidentes: usar um arraylimita a escalabilidade e as opções de pesquisa porque não possui indexação de texto, radicalização e suporte de inflexão, mas é fácil de usar quando uma correspondência exata é desejada. O uso de um tipo de textdados é mais flexível ao pesquisar strings. O uso de um tipo de dados com uma coluna textgerada fornece maior flexibilidade e bom desempenho em todos os cenários, mas requer mais armazenamento.tsvector