Início / dba / Perguntas / 150595
Accepted
beldaz
Asked: 2016-09-26 01:43:24 +0800 CST

PostgreSQL GiST para tipo de entrada compactada

  • 772

Estou usando o PostgreSQL 9.5 e estou tentando entender como implementar um índice GiST onde tenho uma representação que é uma versão compactada com perdas do tipo indexado. Por exemplo, digamos que eu tenha imagens armazenadas em BYTEAtype e, para o índice, armazeno os intervalos de cores (rmin, rmax, gmin, gmax, bmin, bmax) e desejo comparar imagens com base na semelhança de cores - por exemplo, com um ===operador que retorna true quando as faixas de cores são exatamente iguais, me permitindo facilitar consultas como:

SELECT COUNT(*)
FROM icons, avatars
WHERE icon.image === avatar.image AND avatar.id = 123;

onde iconse avatarssão ambas tabelas com um imagecampo do tipo BYTEA.

Depois de examinar a documentação de implementação, parece que isso deve ser possível. Usando a situação de exemplo acima, acho que poderia fazer o seguinte:

  • o unionmétodo geraria o intervalo delimitador de todas as entradas
  • picksplite penaltyapenas tentaria minimizar os intervalos, semelhante a um R-Tree
  • compresspegaria os dados BYTEA e calcularia a faixa de cores
  • decompressseria uma função identidade
  • consistent(para o ===operador) retornaria verdadeiro se o intervalo de cores da entrada contivesse o intervalo de consulta para nós internos e somente se os intervalos correspondessem exatamente aos nós folha.

É este o caminho certo? Não estou claro sobre quando as etapas de compactação ocorrem. Por exemplo, consistenté presumivelmente chamado várias vezes em diferentes nós da árvore. Então, isso significa que a consulta terá que recalcular o intervalo de cores dos dados da consulta todas as vezes? E no índice, os nós das folhas conterão uma cópia dos dados da imagem ou apenas sua faixa de cores?

Observação O exemplo fornecido é apenas para fins ilustrativos. Minha pergunta é sobre representações com perdas no GiST, não indexando imagens.

postgresql database-internals

2 respostas

  1. Como você já armazena os valores (rmin, rmax, gmin, gmax, bmin, bmax)para a coluna de imagem, um índice btree nessas coberturas verifica a igualdade perfeitamente:

    CREATE INDEX foo1 ON icons (rmin, rmax, gmin, gmax, bmin, bmax);

    Esta consulta usará o índice:

    SELECT COUNT(*)
FROM   avatars a
JOIN   icons   i
WHERE  a.id = 123
AND   (a.rmin, a.rmax, a.gmin, a.gmax, a.bmin, a.bmax)
    = (i.rmin, i.rmax, i.gmin, i.gmax, i.bmin, i.bmax);

    Claro, você precisa de outro índice em avatars.id, ou possivelmente em (id, rmin, rmax, gmin, gmax, bmin, bmax)para permitir varreduras somente de índice.

    • 2
  2. Best Answer

    Como Erwin disse, definir um índice gist personalizado para isso pode ser um exagero.

    Não estou claro sobre quando as etapas de compactação ocorrem. Por exemplo, consistente é presumivelmente chamado várias vezes em diferentes nós da árvore. Então, isso significa que a consulta terá que recalcular o intervalo de cores dos dados da consulta todas as vezes?

    O último parágrafo da documentação a que você se refere informa como armazenar em cache o valor calculado, se desejar. Para um exemplo resolvido, veja o uso de fn_extra em contrib/pg_trgm/trgm_gist.c

    E no índice, os nós das folhas conterão uma cópia dos dados da imagem ou apenas sua faixa de cores?

    Isso depende de como você implementa a função de compactação. A função tem acesso ao conhecimento se é chamada em uma entrada de folha ou em uma entrada não folha. Se você apenas compactar coisas em não-folhas, as folhas não serão compactadas. Portanto, cabe a você.

    • 1

relate perguntas