SQL 결과를 has-many-through 관계로 필터링하는 방법

100

나는 테이블을 가지고 가정 student, club그리고 student_club:

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

축구 (30) 동아리와 야구 (50) 동아리의 모든 학생들을 찾는 방법을 알고 싶습니다.
이 쿼리는 작동하지 않지만 지금까지 가장 가까운 것입니다.

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 
— 제온 크로스
소스

답변:

145

나는 궁금했어. 그리고 우리 모두 알다시피 호기심은 고양이를 죽이는 것으로 유명합니다.

그렇다면 고양이의 피부를 가장 빨리 살리는 방법은 무엇일까요?

이 테스트를위한 정확한 고양이 가죽 환경 :

  • 적절한 RAM 및 설정을 갖춘 Debian Squeeze의 PostgreSQL 9.0 .
  • 학생 6.000 명, 클럽 회원 24.000 명 (실제 데이터와 유사한 데이터베이스에서 복사 한 데이터)
  • 질문에서 명명 스키마에서 약간의 전환 : student.idis student.stud_idand club.idis club.club_idhere.
  • 이 스레드에서 작성자의 이름을 따서 쿼리 이름을 지정했습니다. 인덱스는 2 개입니다.
  • 캐시를 채우기 위해 모든 쿼리를 몇 번 실행 한 다음 EXPLAIN ANALYZE를 사용하여 5 개 중 최고를 선택했습니다.

  • 관련 인덱스 (최적이어야합니다-어떤 클럽이 쿼리 될 것인지에 대한 사전 지식이 부족한 한) :

    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_pkey여기에서 대부분의 쿼리에는 필요하지 않습니다.
    기본 키는 PostgreSQL에서 자동으로 고유 인덱스를 구현합니다.
    마지막 인덱스는 PostgreSQL 에서 다중 열 인덱스 의 알려진 단점을 보완하는 것입니다 .

다중 열 B- 트리 인덱스는 인덱스 열의 하위 집합을 포함하는 쿼리 조건과 함께 사용할 수 있지만 선행 (가장 왼쪽) 열에 제약 조건이있는 경우 인덱스가 가장 효율적입니다.

결과 :

EXPLAIN ANALYZE의 총 런타임.

1) 마틴 2 : 44.594ms

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.217ms

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) 마틴 1 : 31.735ms

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) 데릭 : 2.287ms

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.181ms

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.043ms

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;

마지막 세 개는 거의 동일하게 수행됩니다. 4) 및 5) 결과는 동일한 쿼리 계획입니다.

늦은 추가 :

멋진 SQL이지만 성능이 따라갈 수 없습니다.

7) ypercube 1 : 148.649ms

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.497ms

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  
      )
   );

예상대로이 두 가지는 거의 동일하게 수행됩니다. 쿼리 계획 결과 테이블 스캔이 발생하지만 플래너는 여기서 인덱스를 사용하는 방법을 찾지 못합니다.

9) wildplasser 1 : 49.849ms

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, CTE를위한 괜찮은 성능. 매우 이국적인 쿼리 계획.
다시 말하지만 9.1이 이것을 어떻게 처리하는지 흥미로울 것입니다. 여기서 사용하는 db 클러스터를 곧 9.1로 업그레이드 할 예정입니다. 아마 나는 전체 shebang을 다시 실행할 것입니다 ...

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);

쿼리 2의 CTE 변형). 놀랍게도 정확히 동일한 데이터를 사용하는 쿼리 계획이 약간 다를 수 있습니다. student하위 쿼리 변형이 인덱스를 사용하는에서 순차 스캔을 찾았습니다 .

11) ypercube 3 : 101.482ms

또 다른 늦은 추가 @ypercube. 얼마나 많은 방법이 있는지 긍정적으로 놀랍습니다.

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) 어윈 3 : 2.377ms

@ypercube의 11)은 실제로이 단순한 변형의 마음을 뒤틀는 역방향 접근 방식이며 여전히 누락되었습니다. 최고 고양이만큼 빠르게 수행합니다.

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) 어윈 4 : 2.375ms

믿기 ​​어렵지만 여기에 또 다른 진정으로 새로운 변형이 있습니다. 두 개 이상의 멤버십에 대한 잠재력이 있다고 생각하지만 두 명만있는 최고의 고양이 중 하나이기도합니다.

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
   )

동적 클럽 회원 수

즉, 다양한 필터 수입니다. 이 질문은 정확히 두 개의 클럽 회원을 요구했습니다 . 그러나 많은 사용 사례는 다양한 수에 대비해야합니다.

이 관련 이후 답변에 대한 자세한 설명은 다음과 같습니다.

— Erwin Brandstetter
소스
1
Brandstetter, 아주 잘 했어요. 나는 당신에게 추가 크레딧을주기 위해이 질문에 대한 현상금을 시작했습니다 (하지만 24 시간을 기다려야합니다). 당신이 ... 여러 club_id가 대신 두의 추가 시작할 때 어쨌든, 나는이 쿼리를 이동하는 방법을 궁금해
— Xeoncross
@Xeoncross : 너의 관대 한 제스처에 대한 찬사. :) club_ids가 많을수록 1) 및 2) 속도가 가까워 질 것으로 생각되지만 순위를 무너 뜨리려면 더 큰 숫자가되어야합니다.
— Erwin Brandstetter 2011 년
클럽이 두 개 이상있는 경우 해당 클럽을 포함하는 다른 테이블을 만듭니다. 그런 다음 선택한 테이블에 조인하십시오.
— Paul Morgan
@Erwin : Thnx (벤치 마크 용). nitpicking은 아니지만 아마도 (student_id, club_id)(또는 그 반대) 인덱스를 사용하여 이러한 쿼리를 시도해 볼 수 있습니다 .
— ypercubeᵀᴹ
3
문제의 도메인과 샘플 크기를 고려할 때 200ms 미만의 모든 것이 허용 가능한 성능이라고 생각하는 것이 잘못입니까? 개인적인 관심을 위해 동일한 구조 인덱스와 데이터 확산을 사용하여 SQL Server 2008 R2에서 자체 테스트를 수행했지만 수백만 명의 학생 (주어진 도메인에 대해 상당히 큰 집합)으로 확장했지만 여전히 서로 다른 접근 방식을 분리하는 것이 많지 않습니다, IMO. 물론 관계형 분할을 기반으로하는 것은 기본 테이블을 대상으로하여 '확장 성'이라는 이점을 제공 할 수 있습니다.
— onedaywhen
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
— 션
소스
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)
— 데릭 크롬
소스
이 쿼리는 잘 작동하지만 RDBMS에 너무 많은 인덱스 * 클럽 수를 확인하도록 요청해야하는 문제가 있습니다.
— Xeoncross 2011 년
6
이 쿼리는 깨끗한 스타일과 비슷하기 때문에 가장 좋아합니다. SQL의 python과 같습니다. 나는 이러한 종류의 코드에 대해 0.44ms (Sean의 쿼리와 차이)를 행복하게 교환 할 것입니다.
— MGP 2013 년
5

student_id를 원하면 다음을 수행하십시오.

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

학생의 이름도 필요하면 :

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 )

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 ) )
— 폴 모건
소스
처음 두 개는 내 쿼리 1에 포함되어 있습니다. 그러나 세 번째는 위의 주석에 @Xeoncross '가 추가 한 질문에 대해 설명합니다. 나는 속임수없이 그 부분에 투표 할 것입니다.
— Erwin Brandstetter 2011 년
의견을 보내 주셔서 감사하지만 일부 서식도 시연 중입니다. '있는 그대로'두겠습니다.
— 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)

또는 더 쉽게 더 일반적인 솔루션으로 확장하는 n클럽 것을 피합니다 INTERSECT(MySQL을 사용할 수 없습니다) 및 IN(로 이것의 성능이 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
— 마틴 스미스
소스
의심 할 여지없이 두 번째 답변은 코드로 생성되는 쿼리에 가장 적합합니다. 10 개 기준의 관계형 분할을 찾기 위해 10 개의 조인 또는 하위 쿼리를 작성해야합니까? 아니, 대신이 훌륭한 솔루션을 사용하겠습니다. HAVINGMySQL에서 하는 일을 가르쳐 주셔서 감사합니다 .
— Eric L.
4

다른 CTE. 깔끔해 보이지만 일반 하위 쿼리의 groupby와 동일한 계획을 생성 할 수 있습니다.

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)
    ;

테스트하려는 사람들을 위해 내 생성 테스트 데이터 사본 :

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)
    ;
— 야생 플라스터
소스
그래, 그것은 내 첫 번째 버전에서 같은 그룹 별 하위 쿼리입니다. 동일한 쿼리 계획 + CTE 오버 헤드는 CTE에 대해 동일한 성능 + 약간의 결과를 가져옵니다. 그래도 좋은 테스트 설정.
— Erwin Brandstetter 2011 년
CTE 오버 헤드가 있는지 모르겠습니다. 테스트 데이터의 배포는 매우 중요합니다. 통계의 가용성도 마찬가지입니다. VACUUM ANALYZE 후 실행 시간은 67.4ms에서 1.56ms로 늘어났습니다. QP와 관련된 해시 및 비트 맵 만.
— wildplasser
그것은 당신의 경우에 특별합니다. 큰 테이블의 80 %를 삭제하고 많은 것을 업데이트 한 후 다른 것보다 더 많은 죽은 튜플을 가졌습니다. 당연히 진공 분석이 많은 도움이됩니다. CTE를 사용하거나 사용하지 않고 두 변형을 모두 실행했는데 놀랍게도 쿼리 계획이 동일하지 않았습니다. 또는 더 좋은 방법은 채팅방을 열겠습니다.
— Erwin Brandstetter 2011 년
걱정하지 마세요. 80 %의 죽은 행을 알고있었습니다 ... 통계도 중요하다고 생각합니다. 그러나 히스토그램은 무작위로 삭제되므로 오히려 '평평'합니다. 계획자가 계획을 전환하기로 결정하도록 충분히 변경되는 것은 필요한 페이지의 추정치 일 수 있습니다.
— wildplasser
3

따라서 고양이 피부를 만드는 방법은 여러 가지가 있습니다 . 더 완벽하게 만들기 위해 두 개 를 더
추가하겠습니다 .

1) 먼저 GROUP, JOIN 나중에

온전한 데이터 모델 가정 (student_id, club_id)입니다 고유 의를 student_club. Martin Smith의 두 번째 버전은 다소 비슷하지만 먼저 그룹에 합류합니다. 더 빠를 것입니다.

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) 존재

물론 고전적인 EXISTS. Derek의 IN. 간단하고 빠릅니다. (MySQL에서는를 사용하는 변형보다 훨씬 빠릅니다 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
소스
3

아무도이 (클래식) 버전을 추가하지 않았기 때문에 :

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  
              )
      )

또는 유사 :

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  
              )
      )

약간 다른 접근 방식으로 한 번 더 시도하십시오. Explain Extended : EAV 테이블의 여러 속성 : GROUP BY 대 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  
              )
      )

또 다른 접근 방식 :

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ᵀᴹ
소스
+1 .. 완전하지 않은 고양이 가죽 컬렉션에 멋진 추가! :) 벤치 마크에 추가했습니다.
— Erwin Brandstetter 2011 년
이것은 공정한 싸움이 아닙니다 :) 이와 같은 관계형 분할의 큰 장점은 제수가 기본 테이블이 될 수 있으므로 제수를 변경하는 것이 매우 저렴하다는 것입니다. 즉, SQL을 변경하여 동일한 쿼리가 대상으로하는 기본 테이블의 행을 업데이트하는 대비 매번 쿼리하십시오.
— onedaywhen
@ErwinBrandstetter : 테스트에 세 번째 변형을 추가 할 수 있습니까?
— ypercubeᵀᴹ
@ypercube : 알겠습니다. 꽤 꼬인 버전. :)
— Erwin Brandstetter 2012
1
@Erwin : 이것에 시간을 낭비 할 수있을 때, (stud_id, club_id)그리고 (club_id, stud_id)(또는 Primary와 Unique) 둘 다에 두 개의 고유 키를 사용해 볼 수 있습니까? 나는 여전히 이러한 쿼리 중 일부의 경우 2에서 140ms의 차이가 실행 계획의 차이로 설명하기에는 너무 크다고 생각합니다.
— 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

    ;

CTE 스캔은 두 개의 개별 하위 쿼리가 필요하지 않기 때문에 이것은 합리적으로 잘 수행되는 것 같습니다.

재귀 쿼리를 오용하는 이유는 항상 있습니다!

(BTW : mysql에는 재귀 쿼리가없는 것 같습니다)

— 야생 플라스터
소스
그것에 대한 또 다른 적절한 방법을 찾으면 +1! 벤치 마크에 검색어를 추가했습니다. 괜찮 으시길 바랍니다. :)
— Erwin Brandstetter
괜찮아. 그러나 그것은 물론 농담으로 의도되었습니다. CTE는 더 많은 '잘못된'학생 * 클럽 기록이 추가되면 실제로 잘 수행됩니다. (테스트를 위해 1000 명의 학생 * 100 개의 동아리를 사용하고 무작위로 80 % 삭제)
— wildplasser
1

쿼리 2) 및 10)의 다른 쿼리 계획

실제 DB에서 테스트했기 때문에 이름이 catskin 목록과 다릅니다. 백업 복사본이므로 모든 테스트 실행 중에 아무것도 변경되지 않았습니다 (카탈로그에 대한 사소한 변경 제외).

쿼리 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

쿼리 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
소스
@wildplasser : 다양한 쿼리 계획을 확인하세요! 나를 위해 예상치 못한. 9.0 페이지. 채팅방이 다루기 어려웠 기 때문에 여기서 답변을 남용합니다.
— Erwin Brandstetter 2011 년
이상한 장면. 기본적으로 CTE에 대한 동일한 QP (9.0.1-beta-something) : 인덱스 스캔 + 병합 대신 seq 스캔 + 비트 맵. 옵티마이 저의 비용 휴리스틱 스의 결함일까요? 나는 또 다른 CTE 남용을 생산할 것입니다 ...
— wildplasser
1

@ erwin-brandstetter 제발, 이것을 벤치마킹하십시오 :

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;

@sean의 번호 6)처럼 깨끗합니다.

— 타 아이
소스
2
@-notifying은 답변이 아닌 댓글에서만 작동 한다는 것을 알아야합니다 . 나는 우연히이 게시물을 우연히 발견했습니다. 쿼리 계획 및 쿼리 성능은 Sean의 쿼리와 동일합니다. 사실상 동일하지만 명시 적 JOIN구문을 사용한 Sean의 쿼리가 더 명확하기 때문에 일반적으로 선호되는 형식입니다. 그래도 또 다른 유효한 대답은 +1입니다!
— Erwin Brandstetter 2012-06-14
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)
    ;

쿼리 계획 :

 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)

그래서 여전히 학생에 대한 seq 스캔을 원하는 것 같습니다.

— 야생 플라스터
소스
9.1에서 수정되었는지 기다릴 수 없습니다.
— Erwin Brandstetter 2011 년
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
;

가장 빠른 변형 사용 (Mr. Brandstetter 차트의 Mr. Sean). 단 하나의 조인으로 변형 될 수 있습니다. student_club 매트릭스에만 살 권리가 있습니다. 따라서 가장 긴 쿼리에는 계산할 열이 두 개뿐입니다. 아이디어는 쿼리를 얇게 만드는 것입니다.

— 스테판 파블로프
소스
1
이 코드 스 니펫은 질문을 해결할 수 있지만 설명을 포함하면 게시물의 품질을 개선하는 데 실제로 도움이됩니다 . 지금 질문하는 사람뿐만 아니라 미래에 독자를 위해 질문에 답하고 있다는 것을 기억하십시오! 제발 편집 설명을 추가하고, 제한 및 가정이 적용 무엇의 표시를 제공하는 답변을.
— BrokenBinary
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.