Início / dba / Perguntas / 155972
Accepted
Dan
Asked: 2016-11-22 19:03:41 +0800 CST

Condições Postgres JOIN vs condições WHERE

  • 772

Postgres novato aqui.

Eu estou querendo saber se esta consulta é otimizada ou não? Tentei JOIN ON apenas os valores que são 100% necessários e deixando todas as condições dinâmicas na cláusula WHERE. Veja abaixo.

SELECT *
    FROM
      myapp_employees
    JOIN myapp_users ON
      myapp_users.user_id=myapp_employees.user_id
    JOIN myapp_contacts_assoc ON
      myapp_contacts_assoc.user_id=myapp_users.user_id
    JOIN myapp_contacts ON
      myapp_contacts.contact_id=myapp_contacts_assoc.contact_id
    WHERE
      myapp_contacts.value='[email protected]' AND
      myapp_contacts.type=(1)::INT2 AND
      myapp_contacts.is_primary=(1)::INT2 AND
      myapp_contacts.expired_at IS NULL AND
      myapp_employees.status=(1)::INT2 AND
      myapp_users.status=(1)::INT2
    LIMIT 1;

Nota: Por contexto, este proc está verificando se um usuário também é um funcionário (privs elevados/tipo de usuário diferente).

De qualquer forma, este é o caminho certo a seguir? O JOIN ON deve conter mais instruções como verificar expired_at IS NULL, por exemplo? Por que ou por que isso não faz sentido?

postgresql join

2 respostas

  1. Best Answer

    Logicamente , não faz diferença se você coloca condições na cláusula join de an INNER JOINou na WHEREcláusula do mesmo SELECT. O efeito é o mesmo.

    (Não é o caso de OUTER JOIN!)

    Ao operar com configurações padrão, também não faz diferença para o plano de consulta ou desempenho . O Postgres é livre para reorganizar junções e JOIN& WHEREcondições em sua busca pelo melhor plano de consulta - desde que o número de tabelas não seja maior que join_collapse_limit(padrão 8). Detalhes:

    Para legibilidade e manutenção , faz sentido colocar condições que conectam tabelas na respectiva JOINcláusula e condições gerais na WHEREcláusula.

    Sua consulta parece muito bem. No entanto, eu usaria apelidos de tabela para reduzir o ruído.

    Detalhe menor:

    int2 '1'ou mesmo 1::int2são mais sensatos do que (1)::INT2. E ao comparar com um valor de tipo de dados numérico bem definido, uma constante numérica simples 1também é boa o suficiente.

    • 23

  2. Alguns pontos..

    1. Se você estiver participando de uma condição com o mesmo nome ( user_id) no seu caso, poderá usar USING (user_id)em vez de ON (a.user_id = b.user_id). Isso também evita que uma coluna redundante seja potencialmente gerada (se você estiver executando SELECT *em produção).

    2. 1::int2é problemático. Ou status, e is_primarye outros já estão int2, caso em que o literal 1 será automaticamente convertido em int2, ou int2 convertido em int conforme pg achar adequado. Ou, se você estiver armazenando-os como inteiros regulares e lançando-os como se isso fizesse diferença na computação - o que não faz, o elenco sozinho torna isso uma proposta perdedora.

    3. Quando possível, todos os ::int2 provavelmente devem ser armazenados como arquivos boolean. Então você pode escrever sua WHEREcondição para ser mais simples também.

    4. Para seu tipo e status, você pode querer um ENUMtipo.

    • 3

relate perguntas