Como filtrar resultados de SQL em uma relação has-many-through

100

Supondo que eu tenho as tabelas student, clube student_club:

student {
    id
    name
}
club {
    id
    name
}
student_club {
    student_id
    club_id
}

Quero saber como localizar todos os alunos do clube de futebol (30) e beisebol (50).
Embora essa consulta não funcione, é a coisa mais próxima que tenho até agora:

SELECT student.*
FROM   student
INNER  JOIN student_club sc ON student.id = sc.student_id
LEFT   JOIN club c ON c.id = sc.club_id
WHERE  c.id = 30 AND c.id = 50
mysql  sql  postgresql  sql-match-all  relational-division 
— Xeoncross
fonte

Respostas:

145

Eu estava curioso. E, como todos sabemos, a curiosidade tem a reputação de matar gatos.

Então, qual é a maneira mais rápida de esfolar um gato?

O ambiente preciso de pele de gato para este teste:

  • PostgreSQL 9.0 no Debian Squeeze com RAM e configurações decentes.
  • 6.000 alunos, 24.000 membros do clube (dados copiados de um banco de dados semelhante com dados da vida real.)
  • Ligeiro desvio do esquema de nomenclatura na questão: student.idé student.stud_ide club.idéclub.club_id aqui.
  • Nomeei as consultas com o nome de seu autor neste tópico, com um índice onde há dois.
  • Executei todas as consultas algumas vezes para preencher o cache, então escolhi a melhor de 5 com EXPLAIN ANALYZE.

  • Índices relevantes (devem ser os melhores - desde que não tenhamos conhecimento prévio de quais clubes serão consultados):

    ALTER TABLE student ADD CONSTRAINT student_pkey PRIMARY KEY(stud_id );
ALTER TABLE student_club ADD CONSTRAINT sc_pkey PRIMARY KEY(stud_id, club_id);
ALTER TABLE club       ADD CONSTRAINT club_pkey PRIMARY KEY(club_id );
CREATE INDEX sc_club_id_idx ON student_club (club_id);

    club_pkeynão é exigido pela maioria das consultas aqui.
    As chaves primárias implementam índices únicos automaticamente no PostgreSQL.
    O último índice é para compensar esta deficiência conhecida de índices com várias colunas no PostgreSQL:

Um índice de árvore B com várias colunas pode ser usado com condições de consulta que envolvem qualquer subconjunto das colunas do índice, mas o índice é mais eficiente quando há restrições nas colunas iniciais (mais à esquerda).

Resultados:

Tempo de execução total de EXPLAIN ANALYZE.

1) Martin 2: 44,594 ms

SELECT s.stud_id, s.name
FROM   student s
JOIN   student_club sc USING (stud_id)
WHERE  sc.club_id IN (30, 50)
GROUP  BY 1,2
HAVING COUNT(*) > 1;

2) Erwin 1: 33,217 ms

SELECT s.stud_id, s.name
FROM   student s
JOIN   (
   SELECT stud_id
   FROM   student_club
   WHERE  club_id IN (30, 50)
   GROUP  BY 1
   HAVING COUNT(*) > 1
   ) sc USING (stud_id);

3) Martin 1: 31,735 ms

SELECT s.stud_id, s.name
   FROM   student s
   WHERE  student_id IN (
   SELECT student_id
   FROM   student_club
   WHERE  club_id = 30
   INTERSECT
   SELECT stud_id
   FROM   student_club
   WHERE  club_id = 50);

4) Derek: 2,287 ms

SELECT s.stud_id,  s.name
FROM   student s
WHERE  s.stud_id IN (SELECT stud_id FROM student_club WHERE club_id = 30)
AND    s.stud_id IN (SELECT stud_id FROM student_club WHERE club_id = 50);

5) Erwin 2: 2,181 ms

SELECT s.stud_id,  s.name
FROM   student s
WHERE  EXISTS (SELECT * FROM student_club
               WHERE  stud_id = s.stud_id AND club_id = 30)
AND    EXISTS (SELECT * FROM student_club
               WHERE  stud_id = s.stud_id AND club_id = 50);

6) Sean: 2,043 ms

SELECT s.stud_id, s.name
FROM   student s
JOIN   student_club x ON s.stud_id = x.stud_id
JOIN   student_club y ON s.stud_id = y.stud_id
WHERE  x.club_id = 30
AND    y.club_id = 50;

Os três últimos têm praticamente o mesmo desempenho. 4) e 5) resultam no mesmo plano de consulta.

Adições tardias:

SQL extravagante, mas o desempenho não consegue acompanhar.

7) ypercube 1: 148.649 ms

SELECT s.stud_id,  s.name
FROM   student AS s
WHERE  NOT EXISTS (
   SELECT *
   FROM   club AS c 
   WHERE  c.club_id IN (30, 50)
   AND    NOT EXISTS (
      SELECT *
      FROM   student_club AS sc 
      WHERE  sc.stud_id = s.stud_id
      AND    sc.club_id = c.club_id  
      )
   );

8) ypercube 2: 147,497 ms

SELECT s.stud_id,  s.name
FROM   student AS s
WHERE  NOT EXISTS (
   SELECT *
   FROM  (
      SELECT 30 AS club_id  
      UNION  ALL
      SELECT 50
      ) AS c
   WHERE NOT EXISTS (
      SELECT *
      FROM   student_club AS sc 
      WHERE  sc.stud_id = s.stud_id
      AND    sc.club_id = c.club_id  
      )
   );

Como esperado, esses dois desempenham quase o mesmo. O plano de consulta resulta em varreduras de tabela, o planejador não encontra uma maneira de usar os índices aqui.

9) wildplasser 1: 49,849 ms

WITH RECURSIVE two AS (
   SELECT 1::int AS level
        , stud_id
   FROM   student_club sc1
   WHERE  sc1.club_id = 30
   UNION
   SELECT two.level + 1 AS level
        , sc2.stud_id
   FROM   student_club sc2
   JOIN   two USING (stud_id)
   WHERE  sc2.club_id = 50
   AND    two.level = 1
   )
SELECT s.stud_id, s.student
FROM   student s
JOIN   two USING (studid)
WHERE  two.level > 1;

SQL extravagante, desempenho decente para um CTE. Plano de consulta muito exótico.
Novamente, seria interessante como o 9.1 lida com isso. Vou atualizar o cluster db usado aqui para 9.1 em breve. Talvez eu reexecute a coisa toda ...

10) wildplasser 2: 36,986 ms

WITH sc AS (
   SELECT stud_id
   FROM   student_club
   WHERE  club_id IN (30,50)
   GROUP  BY stud_id
   HAVING COUNT(*) > 1
   )
SELECT s.*
FROM   student s
JOIN   sc USING (stud_id);

Variante CTE da consulta 2). Surpreendentemente, isso pode resultar em um plano de consulta ligeiramente diferente com exatamente os mesmos dados. Encontrei uma varredura sequencial em student, onde a variante de subconsulta usou o índice.

11) ypercube 3: 101.482 ms

Outra adição tardia, @ypercube. É positivamente incrível, quantas maneiras existem.

SELECT s.stud_id, s.student
FROM   student s
JOIN   student_club sc USING (stud_id)
WHERE  sc.club_id = 10                 -- member in 1st club ...
AND    NOT EXISTS (
   SELECT *
   FROM  (SELECT 14 AS club_id) AS c  -- can't be excluded for missing the 2nd
   WHERE  NOT EXISTS (
      SELECT *
      FROM   student_club AS d
      WHERE  d.stud_id = sc.stud_id
      AND    d.club_id = c.club_id
      )
   )

12) erwin 3: 2,377 ms

@ ypercube's 11) é, na verdade, apenas a abordagem reversa doentia dessa variante mais simples, que também estava faltando. Tem um desempenho quase tão rápido quanto os melhores.

SELECT s.*
FROM   student s
JOIN   student_club x USING (stud_id)
WHERE  sc.club_id = 10                 -- member in 1st club ...
AND    EXISTS (                        -- ... and membership in 2nd exists
   SELECT *
   FROM   student_club AS y
   WHERE  y.stud_id = s.stud_id
   AND    y.club_id = 14
   )

13) erwin 4: 2,375 ms

Difícil de acreditar, mas aqui está outra variante genuinamente nova. Vejo potencial para mais de duas associações, mas também está entre os principais felinos, com apenas duas.

SELECT s.*
FROM   student AS s
WHERE  EXISTS (
   SELECT *
   FROM   student_club AS x
   JOIN   student_club AS y USING (stud_id)
   WHERE  x.stud_id = s.stud_id
   AND    x.club_id = 14
   AND    y.club_id = 10
   )

Número dinâmico de membros do clube

Em outras palavras: número variável de filtros. Esta pergunta pedia exatamente duas associações de clube. Mas muitos casos de uso precisam se preparar para um número variável.

Discussão detalhada nesta resposta posterior relacionada:

— Erwin Brandstetter
fonte
1
Brandstetter, muito bom trabalho. Comecei uma recompensa por essa questão para lhe dar crédito extra (mas tenho que esperar 24 horas). De qualquer forma, gostaria de saber como essas consultas vão quando você começa a adicionar vários club_ids em vez de apenas dois ...
— Xeoncross
@Xeoncross: Parabéns pelo seu gesto generoso. :) Com mais club_ids eu suspeito que 1) e 2) vão se aproximar em velocidade, mas teria que ser um número maior para derrubar o ranking.
— Erwin Brandstetter,
se você tiver mais de dois tacos, crie outra mesa que contenha esses tacos. Em seguida, junte-se a essa mesa em sua seleção.
— Paul Morgan,
@Erwin: Thnx (para os benchmarks). Não criticar, mas talvez você possa tentar essas consultas (quero dizer, todas, não apenas as minhas) com um (student_id, club_id)índice (ou o inverso).
— ypercubeᵀᴹ
3
Estou errado em pensar que algo abaixo de 200 ms é um desempenho aceitável, dado o domínio em questão e o tamanho da amostra? Por interesse pessoal, realizei meus próprios testes no SQL Server 2008 R2 usando os mesmos índices de estrutura e (eu acho) disseminação de dados, mas escalando para um milhão de alunos (um conjunto razoavelmente grande para o domínio dado, eu acho) e ainda não havia não é muito para separar as diferentes abordagens, IMO. Claro, aqueles baseados na divisão relacional podem ter como alvo uma tabela base, dando-lhes a vantagem de 'extensibilidade'.
— dia em
18 
SELECT s.*
FROM student s
INNER JOIN student_club sc_soccer ON s.id = sc_soccer.student_id
INNER JOIN student_club sc_baseball ON s.id = sc_baseball.student_id
WHERE 
 sc_baseball.club_id = 50 AND 
 sc_soccer.club_id = 30
— Sean
fonte
10 
select *
from student
where id in (select student_id from student_club where club_id = 30)
and id in (select student_id from student_club where club_id = 50)
— Derek Kromm
fonte
Essa consulta funciona bem, mas algo me incomoda em ter que pedir ao RDBMS para verificar tantos índices * o número de clubes.
— Xeoncross,
6
Eu gosto mais dessa consulta porque se assemelha a um estilo limpo, é como python em sql. Eu trocaria felizmente 0,44 ms (diferença com a consulta de Sean) por esse tipo de código.
— MGP
5

Se você quer apenas student_id, então:

    Select student_id
      from student_club
     where club_id in ( 30, 50 )
  group by student_id
    having count( student_id ) = 2

Se você também precisa do nome do aluno:

Select student_id, name
  from student s
 where exists( select *
                 from student_club sc
                where s.student_id = sc.student_id
                  and club_id in ( 30, 50 )
             group by sc.student_id
               having count( sc.student_id ) = 2 )

Se você tiver mais de dois clubes em uma tabela club_selection:

Select student_id, name
  from student s
 where exists( select *
                 from student_club sc
                where s.student_id = sc.student_id
                  and exists( select * 
                                from club_selection cs
                               where sc.club_id = cs.club_id )
             group by sc.student_id
               having count( sc.student_id ) = ( select count( * )
                                                   from club_selection ) )
— Paul Morgan
fonte
Os dois primeiros estão incluídos em / o mesmo que minha consulta 1. Mas o terceiro aborda a pergunta adicionada de @Xeoncross nos comentários acima. Eu votaria nessa parte sem os idiotas.
— Erwin Brandstetter,
Obrigado pelo comentário, mas também estou demonstrando alguma formatação. Vou deixar 'como está'.
— Paul Morgan,
4 
SELECT *
FROM   student
WHERE  id IN (SELECT student_id
              FROM   student_club
              WHERE  club_id = 30
              INTERSECT
              SELECT student_id
              FROM   student_club
              WHERE  club_id = 50)

Ou uma solução mais geral mais fácil de estender para nclubes e que evita INTERSECT(não disponível no MySQL) e IN(já que o desempenho disso é péssimo no MySQL )

SELECT s.id,
       s.name
FROM   student s
       join student_club sc
         ON s.id = sc.student_id
WHERE  sc.club_id IN ( 30, 50 )
GROUP  BY s.id,
          s.name
HAVING COUNT(DISTINCT sc.club_id) = 2
— Martin Smith
fonte
Sem dúvida, sua segunda resposta é a melhor para as consultas que estão sendo geradas por código. Vou realmente escrever 10 junções ou subconsultas para encontrar a divisão relacional de 10 critérios? Caramba, não, vou usar esta solução brilhante, em vez disso. Obrigado por me ensinar o que HAVINGfaz no MySQL.
— Eric L.
4

Outro CTE. Parece limpo, mas provavelmente irá gerar o mesmo plano que um groupby em uma subconsulta normal.

WITH two AS (
    SELECT student_id FROM tmp.student_club
    WHERE club_id IN (30,50)
    GROUP BY student_id
    HAVING COUNT(*) > 1
    )
SELECT st.* FROM tmp.student st
JOIN two ON (two.student_id=st.id)
    ;

Para quem quiser testar, uma cópia do meu objeto de gerar dados de teste:

DROP SCHEMA tmp CASCADE;
CREATE SCHEMA tmp;

CREATE TABLE tmp.student
    ( id INTEGER NOT NULL PRIMARY KEY
    , sname VARCHAR
    );

CREATE TABLE tmp.club
    ( id INTEGER NOT NULL PRIMARY KEY
    , cname VARCHAR
    );

CREATE TABLE tmp.student_club
    ( student_id INTEGER NOT NULL  REFERENCES tmp.student(id)
    , club_id INTEGER NOT NULL  REFERENCES tmp.club(id)
    );

INSERT INTO tmp.student(id)
    SELECT generate_series(1,1000)
    ;

INSERT INTO tmp.club(id)
    SELECT generate_series(1,100)
    ;

INSERT INTO tmp.student_club(student_id,club_id)
    SELECT st.id  , cl.id
    FROM tmp.student st, tmp.club cl
    ;

DELETE FROM tmp.student_club
WHERE random() < 0.8
    ;

UPDATE tmp.student SET sname = 'Student#' || id::text ;
UPDATE tmp.club SET cname = 'Soccer' WHERE id = 30;
UPDATE tmp.club SET cname = 'Baseball' WHERE id = 50;

ALTER TABLE tmp.student_club
    ADD PRIMARY KEY (student_id,club_id)
    ;
— Wildplasser
fonte
Sim, isso é apenas uma subconsulta com group by como na minha primeira versão. Mesmo plano de consulta + sobrecarga de CTE resulta no mesmo desempenho + um pouco para o CTE. Boa configuração de teste, no entanto.
— Erwin Brandstetter,
Não sei se há sobrecarga de CTE. A distribuição dos dados de teste é muito importante. O mesmo acontece com a disponibilidade de estatísticas: após VACUUM ANALYZE, o tempo de execução passou de 67,4 para 1,56 ms. Apenas hash e bitmaps envolvidos no QP.
— wildplasser
Isso é especial no seu caso, depois de deletar 80% de uma grande mesa e atualizar bastante, você tinha mais tuplas mortas do que qualquer outra coisa. Não é à toa que a análise de vácuo ajuda muito. Executei as duas variantes com e sem CTE e, surpreendentemente, os planos de consulta não eram idênticos. ou melhor ainda, abrirei um chat para isso.
— Erwin Brandstetter,
Não se preocupe, eu sabia sobre os 80% das linhas mortas ... Acho que as estatísticas também importam. Mas o histograma é bastante "plano", dado a exclusão aleatória. Talvez seja apenas a estimativa de páginas necessárias que muda o suficiente para fazer o planejador decidir mudar de plano.
— wildplasser
3

Portanto, há mais de uma maneira de esfolar um gato .
Vou adicionar mais dois para torná-lo, bem, mais completo.

1) GRUPO primeiro, JUNTE-SE depois

Assumindo um modelo de dados sane onde (student_id, club_id)é única no student_club. A segunda versão de Martin Smith é algo semelhante, mas ele se junta primeiro aos grupos depois. Isso deve ser mais rápido:

SELECT s.id, s.name
  FROM student s
  JOIN (
   SELECT student_id
     FROM student_club
    WHERE club_id IN (30, 50)
    GROUP BY 1
   HAVING COUNT(*) > 1
       ) sc USING (student_id);

2) EXISTE

E, claro, existe o clássico EXISTS. Semelhante à variante de Derek com IN. Simples e rápido. (No MySQL, isso deve ser um pouco mais rápido do que a variante com IN):

SELECT s.id, s.name
  FROM student s
 WHERE EXISTS (SELECT 1 FROM student_club
               WHERE  student_id = s.student_id AND club_id = 30)
   AND EXISTS (SELECT 1 FROM student_club
               WHERE  student_id = s.student_id AND club_id = 50);
— Erwin Brandstetter
fonte
3

Como ninguém adicionou esta versão (clássica):

SELECT s.*
FROM student AS s
WHERE NOT EXISTS
      ( SELECT *
        FROM club AS c 
        WHERE c.id IN (30, 50)
          AND NOT EXISTS
              ( SELECT *
                FROM student_club AS sc 
                WHERE sc.student_id = s.id
                  AND sc.club_id = c.id  
              )
      )

ou similar:

SELECT s.*
FROM student AS s
WHERE NOT EXISTS
      ( SELECT *
        FROM
          ( SELECT 30 AS club_id  
          UNION ALL
            SELECT 50
          ) AS c
        WHERE NOT EXISTS
              ( SELECT *
                FROM student_club AS sc 
                WHERE sc.student_id = s.id
                  AND sc.club_id = c.club_id  
              )
      )

Mais uma tentativa com uma abordagem ligeiramente diferente. Inspirado por um artigo em Explain Extended: vários atributos em uma tabela EAV: GROUP BY vs. NOT EXISTS :

SELECT s.*
FROM student_club AS sc
  JOIN student AS s
    ON s.student_id = sc.student_id
WHERE sc.club_id = 50                      --- one option here
  AND NOT EXISTS
      ( SELECT *
        FROM
          ( SELECT 30 AS club_id           --- all the rest in here
                                           --- as in previous query
          ) AS c
        WHERE NOT EXISTS
              ( SELECT *
                FROM student_club AS scc 
                WHERE scc.student_id = sc.id
                  AND scc.club_id = c.club_id  
              )
      )

Outra abordagem:

SELECT s.stud_id
FROM   student s

EXCEPT

SELECT stud_id
FROM 
  ( SELECT s.stud_id, c.club_id
    FROM student s 
      CROSS JOIN (VALUES (30),(50)) c (club_id)
  EXCEPT
    SELECT stud_id, club_id
    FROM student_club
    WHERE club_id IN (30, 50)   -- optional. Not needed but may affect performance
  ) x ;
— ypercubeᵀᴹ
fonte
+1 .. agradáveis ​​adições à coleção de peles de gato não tão completa! :) Eu os adicionei ao benchmark.
— Erwin Brandstetter,
Não é uma luta justa :) A grande vantagem de uma divisão relacional como esta é que o divisor pode ser uma tabela base, de modo que alterar o divisor é muito barato, ou seja, comparar a atualização de linhas em uma tabela base direcionada pela mesma consulta com a alteração do SQL consulta cada vez.
— dia em
@ErwinBrandstetter: Seria possível adicionar a 3ª variação em seus testes?
— ypercubeᵀᴹ
@ypercube: É isso aí. Versão bem distorcida. :)
— Erwin Brandstetter
1
@Erwin: Quando você consegue perder algum tempo com isso, você também pode tentar ter duas Chaves ÚNICAS, em ambas (stud_id, club_id)e (club_id, stud_id)(ou Primária e Única)? Ainda acho que, para algumas dessas consultas, a diferença de 2 a 140 ms é muito alta para ser explicada pelas diferenças nos planos de execução.
— ypercubeᵀᴹ
2 
WITH RECURSIVE two AS
    ( SELECT 1::integer AS level
    , student_id
    FROM tmp.student_club sc0
    WHERE sc0.club_id = 30
    UNION
    SELECT 1+two.level AS level
    , sc1.student_id
    FROM tmp.student_club sc1
    JOIN two ON (two.student_id = sc1.student_id)
    WHERE sc1.club_id = 50
    AND two.level=1
    )
SELECT st.* FROM tmp.student st
JOIN two ON (two.student_id=st.id)
WHERE two.level> 1

    ;

Isso parece funcionar razoavelmente bem, uma vez que o CTE-scan evita a necessidade de duas subconsultas separadas.

Sempre há um motivo para o uso indevido de consultas recursivas!

(BTW: mysql não parece ter consultas recursivas)

— Wildplasser
fonte
1 por encontrar outro meio decente de caminho para isso! Eu adicionei sua consulta ao benchmark. Espero que esteja tudo bem com você. :)
— Erwin Brandstetter
Está certo. Mas era para ser uma piada, é claro. O CTE realmente tem um bom desempenho se forem adicionados mais registros de clube de alunos 'perdidos'. (Para o teste, usei 1.000 alunos * 100 clubes e excluí 80% aleatoriamente)
— wildplasser
1

Planos de consulta diferentes na consulta 2) e 10)

Eu testei em um banco de dados real, então os nomes são diferentes da lista de gatos. É uma cópia de backup, portanto, nada mudou durante todas as execuções de teste (exceto pequenas alterações nos catálogos).

Consulta 2)

SELECT a.*
FROM   ef.adr a
JOIN (
    SELECT adr_id
    FROM   ef.adratt
    WHERE  att_id IN (10,14)
    GROUP  BY adr_id
    HAVING COUNT(*) > 1) t using (adr_id);

Merge Join  (cost=630.10..1248.78 rows=627 width=295) (actual time=13.025..34.726 rows=67 loops=1)
  Merge Cond: (a.adr_id = adratt.adr_id)
  ->  Index Scan using adr_pkey on adr a  (cost=0.00..523.39 rows=5767 width=295) (actual time=0.023..11.308 rows=5356 loops=1)
  ->  Sort  (cost=630.10..636.37 rows=627 width=4) (actual time=12.891..13.004 rows=67 loops=1)
        Sort Key: adratt.adr_id
        Sort Method:  quicksort  Memory: 28kB
        ->  HashAggregate  (cost=450.87..488.49 rows=627 width=4) (actual time=12.386..12.710 rows=67 loops=1)
              Filter: (count(*) > 1)
              ->  Bitmap Heap Scan on adratt  (cost=97.66..394.81 rows=2803 width=4) (actual time=0.245..5.958 rows=2811 loops=1)
                    Recheck Cond: (att_id = ANY ('{10,14}'::integer[]))
                    ->  Bitmap Index Scan on adratt_att_id_idx  (cost=0.00..94.86 rows=2803 width=0) (actual time=0.217..0.217 rows=2811 loops=1)
                          Index Cond: (att_id = ANY ('{10,14}'::integer[]))
Total runtime: 34.928 ms

Consulta 10)

WITH two AS (
    SELECT adr_id
    FROM   ef.adratt
    WHERE  att_id IN (10,14)
    GROUP  BY adr_id
    HAVING COUNT(*) > 1
    )
SELECT a.*
FROM   ef.adr a
JOIN   two using (adr_id);

Hash Join  (cost=1161.52..1261.84 rows=627 width=295) (actual time=36.188..37.269 rows=67 loops=1)
  Hash Cond: (two.adr_id = a.adr_id)
  CTE two
    ->  HashAggregate  (cost=450.87..488.49 rows=627 width=4) (actual time=13.059..13.447 rows=67 loops=1)
          Filter: (count(*) > 1)
          ->  Bitmap Heap Scan on adratt  (cost=97.66..394.81 rows=2803 width=4) (actual time=0.252..6.252 rows=2811 loops=1)
                Recheck Cond: (att_id = ANY ('{10,14}'::integer[]))
                ->  Bitmap Index Scan on adratt_att_id_idx  (cost=0.00..94.86 rows=2803 width=0) (actual time=0.226..0.226 rows=2811 loops=1)
                      Index Cond: (att_id = ANY ('{10,14}'::integer[]))
  ->  CTE Scan on two  (cost=0.00..50.16 rows=627 width=4) (actual time=13.065..13.677 rows=67 loops=1)
  ->  Hash  (cost=384.68..384.68 rows=5767 width=295) (actual time=23.097..23.097 rows=5767 loops=1)
        Buckets: 1024  Batches: 1  Memory Usage: 1153kB
        ->  Seq Scan on adr a  (cost=0.00..384.68 rows=5767 width=295) (actual time=0.005..10.955 rows=5767 loops=1)
Total runtime: 37.482 ms
— Erwin Brandstetter
fonte
@wildplasser: Veja os planos de consulta divergentes! Inesperado para mim. pg 9.0. A sala de bate-papo era complicada, então abusei de uma resposta aqui.
— Erwin Brandstetter,
Cenas estranhas. Basicamente, o mesmo QP aqui (9.0.1-beta-alguma coisa) para o CTE: varredura de seq + bitmap em vez de varredura de índice + mesclagem. Talvez uma falha na heurística de custo do otimizador? Vou produzir mais um abuso CTE ...
— wildplasser
1

@ erwin-brandstetter Por favor, compare isto:

SELECT s.stud_id, s.name
FROM   student s, student_club x, student_club y
WHERE  x.club_id = 30
AND    s.stud_id = x.stud_id
AND    y.club_id = 50
AND    s.stud_id = y.stud_id;

É como o número 6) por @sean, apenas mais limpo, eu acho.

— Taai
fonte
2
Você deve saber que a @notificação funciona apenas nos comentários, não nas respostas. Eu tropecei neste post por acaso. O plano de consulta e o desempenho de sua consulta são idênticos aos da consulta de Sean. É efetivamente o mesmo, mas a consulta de Sean com JOINsintaxe explícita é a forma geralmente preferida, porque é mais clara. 1 para mais uma resposta válida!
— Erwin Brandstetter
0 
-- EXPLAIN ANALYZE
WITH two AS (
    SELECT c0.student_id
    FROM tmp.student_club c0
    , tmp.student_club c1
    WHERE c0.student_id = c1.student_id
    AND c0.club_id = 30
    AND c1.club_id = 50
    )
SELECT st.* FROM tmp.student st
JOIN two ON (two.student_id=st.id)
    ;

O plano de consulta:

 Hash Join  (cost=1904.76..1919.09 rows=337 width=15) (actual time=6.937..8.771 rows=324 loops=1)
   Hash Cond: (two.student_id = st.id)
   CTE two
     ->  Hash Join  (cost=849.97..1645.76 rows=337 width=4) (actual time=4.932..6.488 rows=324 loops=1)
           Hash Cond: (c1.student_id = c0.student_id)
           ->  Bitmap Heap Scan on student_club c1  (cost=32.76..796.94 rows=1614 width=4) (actual time=0.667..1.835 rows=1646 loops=1)
                 Recheck Cond: (club_id = 50)
                 ->  Bitmap Index Scan on sc_club_id_idx  (cost=0.00..32.36 rows=1614 width=0) (actual time=0.473..0.473 rows=1646 loops=1)                     
                       Index Cond: (club_id = 50)
           ->  Hash  (cost=797.00..797.00 rows=1617 width=4) (actual time=4.203..4.203 rows=1620 loops=1)
                 Buckets: 1024  Batches: 1  Memory Usage: 57kB
                 ->  Bitmap Heap Scan on student_club c0  (cost=32.79..797.00 rows=1617 width=4) (actual time=0.663..3.596 rows=1620 loops=1)                   
                       Recheck Cond: (club_id = 30)
                       ->  Bitmap Index Scan on sc_club_id_idx  (cost=0.00..32.38 rows=1617 width=0) (actual time=0.469..0.469 rows=1620 loops=1)
                             Index Cond: (club_id = 30)
   ->  CTE Scan on two  (cost=0.00..6.74 rows=337 width=4) (actual time=4.935..6.591 rows=324 loops=1)
   ->  Hash  (cost=159.00..159.00 rows=8000 width=15) (actual time=1.979..1.979 rows=8000 loops=1)
         Buckets: 1024  Batches: 1  Memory Usage: 374kB
         ->  Seq Scan on student st  (cost=0.00..159.00 rows=8000 width=15) (actual time=0.093..0.759 rows=8000 loops=1)
 Total runtime: 8.989 ms
(20 rows)

Portanto, ainda parece querer a varredura de seq no aluno.

— Wildplasser
fonte
Mal posso esperar para ver se isso foi corrigido na versão 9.1.
— Erwin Brandstetter,
0 
SELECT s.stud_id, s.name
FROM   student s,
(
select x.stud_id from 
student_club x 
JOIN   student_club y ON x.stud_id = y.stud_id
WHERE  x.club_id = 30
AND    y.club_id = 50
) tmp_tbl
where tmp_tbl.stud_id = s.stud_id
;

Uso da variante mais rápida (Sr. Sean no gráfico do Sr. Brandstetter). Pode ser uma variante com apenas uma junção para apenas a matriz student_club ter o direito de viver. Portanto, a consulta mais longa terá apenas duas colunas para calcular, a ideia é tornar a consulta fina.

— Stepan Pavlov
fonte
1
Embora este snippet de código possa resolver a questão, incluir uma explicação realmente ajuda a melhorar a qualidade de sua postagem. Lembre-se de que você está respondendo às perguntas para os leitores no futuro, não apenas para a pessoa que está perguntando agora! Por favor edite sua resposta para adicionar explicação, e dar uma indicação do que limitações e premissas se aplicam.
— BrokenBinary de
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.