índice HASH PostgreSQL

Question

índice HASH PostgreSQL

votos

27

Alguém sabe uma situação onde um HASH PostgreSQL deve ser usado em vez de um B-TREE pois parece-me que estas coisas são uma armadilha. Eles são tomar forma mais tempo para criar ou manter do que um B-Tree (pelo menos 10 vezes mais), eles também ocupam mais espaço (para um dos meus table.columns, a B-TREE ocupa 240 MB, enquanto um HASH faria ter 4 GB) e eu parecem ter entendido do meu googling, que eles não selecionar mais rapidamente do que árvores-B; mas o HASH pode ter sido recentemente otimizado ou o Google estava errado.

Enfim, eu queria opiniões e experiências de você cara. Se estes hashs são maus, as pessoas devem saber.

Graças
também: o que acontece com hashs do MySQL?

sql postgresql indexing database

Publicado 29/12/2008 em 23:18
fonte usuário Nicholas Leonard

Em outras línguas...

4 respostas

votos

5

Como http://www.postgresql.org/docs/9.2/static/sql-createindex.html índice Hash ponto ainda não são WAL-safe; o que significa que eles não são 100% fiáveis para falhas (índice tem de ser reconstruída e resposta errada pode acontecer em repetições). Verifique também http://www.postgresql.org/docs/9.1/static/wal-intro.html

Respondeu 27/02/2014 em 16:31
fonte usuário Diego Andrés Díaz Espinoza

votos

2

Eu não tentei isso, mas estou considerando essa abordagem, usar índices hash em tabelas não conectado temporários.

O meu entendimento é que eles construir mais rápido, ter menos espaço e consulta ligeiramente mais rápido do b-tree.

De acordo com esta referência , índices de hash são um pouco mais rápido e um pouco menor do que os índices BTREE. No entanto, você não pode fazer um índice hash exclusivo com eles - além disso, eles não são WAL-registrado.

Respondeu 31/07/2014 em 17:31
fonte usuário L. Rodgers

votos

6

É melhor usar um índice hash para colunas de texto que são pesquisados utilizando = operador apenas. Por exemplo, uma coluna de URL que precisa ser indexado para pesquisas.

Um índice de Hash é aproximadamente 30% do tamanho de um índice B-Tree para algo como um URL.

O tamanho reduzido permite ao PostgreSQL usá-lo de memória cache (aka, shared_buffers) de forma mais eficiente.

Respondeu 22/12/2015 em 08:11
fonte usuário Clive Paterson

Kent Fredric · Accepted Answer · 2008-12-29 23:31

Hashes são mais rápidos do B-Trees para casos onde você tem um valor de chave conhecido, especialmente um valor único conhecido.

Hash deve ser utilizado se a coluna em questão é não destina-se a ser digitalizado comparativamente com <ou >comandos.

Hashes são O(1)complexidade, B-árvores são O(log n)complexidade (IIRC), ergo, para grandes tabelas com entradas exclusivas, buscar um ITEM="foo", eles vão ser a maneira mais eficiente de pesquisá-lo.

Isto é especialmente prático quando esses campos exclusivos são usados em uma condição de junção.