Has-çok-geçişli ilişkisinde SQL sonuçlarını filtreleme

101

Ben tablolar varsayarsak student, clubve student_club:

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

Hem futbol (30) hem de beyzbol (50) kulübündeki tüm öğrencileri nasıl bulacağımı bilmek istiyorum.
Bu sorgu işe yaramasa da şu ana kadar sahip olduğum en yakın şey:

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
kaynak

Yanıtlar:

146

Merak ediyordum. Ve hepimizin bildiği gibi, merakın kedileri öldürmekle ünlüdür.

Öyleyse, bir kedinin derisini yüzmenin en hızlı yolu hangisidir?

Bu test için kesin kedi derisi ortamı:

  • İyi RAM ve ayarlarla Debian Squeeze üzerinde PostgreSQL 9.0 .
  • 6.000 öğrenci, 24.000 kulüp üyeliği (veriler gerçek hayat verileriyle benzer bir veritabanından kopyalanır.)
  • Söz konusu adlandırma şeması gelen hafif saptırma: student.idolup student.stud_idve club.idbir club.club_idburaya.
  • Bu konudaki sorguları yazarlarından sonra, iki tane olan indeksle adlandırdım.
  • Önbelleği doldurmak için tüm sorguları birkaç kez çalıştırdım, ardından EXPLAIN ANALYZE ile en iyi 5'i seçtim.

  • İlgili dizinler (optimum olmalıdır - hangi kulüplerin sorgulanacağını önceden bilmediğimiz sürece):

    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_pkeyburadaki çoğu sorgu için gerekli değildir.
    Birincil anahtarlar, benzersiz dizinleri otomatik olarak PostgreSQL'de uygular.
    Son dizin, PostgreSQL'deki çok sütunlu dizinlerin bu bilinen eksikliğini telafi etmektir :

Çok sütunlu bir B-ağaç dizini, dizin sütunlarının herhangi bir alt kümesini içeren sorgu koşullarıyla kullanılabilir, ancak dizin, baştaki (en soldaki) sütunlarda kısıtlamalar olduğunda en etkilidir.

Sonuçlar:

EXPLAIN ANALYZE'dan toplam çalışma süreleri.

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;

Son üçü hemen hemen aynı performansı gösteriyor. 4) ve 5) aynı sorgu planıyla sonuçlanır.

Geç Eklemeler:

Süslü SQL, ancak performans devam edemez.

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

Beklendiği gibi, bu ikisi neredeyse aynı performansı gösteriyor. Sorgu planı tablo taramaları ile sonuçlanır, planlayıcı burada dizinleri kullanmanın bir yolunu bulamaz.

9) vahşi sınıf 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;

Süslü SQL, bir CTE için iyi performans. Çok egzotik sorgu planı.
Yine 9.1'in bunu nasıl ele aldığı ilginç olurdu. Burada kullanılan db kümesini yakında 9.1'e yükselteceğim. Belki bütün meseleyi yeniden çalıştırırım ...

10) vahşi sınıf 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);

Sorgu 2'nin CTE varyantı). Şaşırtıcı bir şekilde, tamamen aynı verilerle biraz farklı bir sorgu planıyla sonuçlanabilir. studentAlt sorgu varyantının dizini kullandığı sıralı bir tarama buldum .

11) ypercube 3: 101,482 ms

Başka bir geç ekleme @ypercube. Kaç tane yol olduğu kesinlikle şaşırtıcı.

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) aslında bu daha basit varyantın akıllara durgunluk veren ters yaklaşımıdır, bu da hala eksikti. Neredeyse en iyi kediler kadar hızlı performans gösterir.

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

İnanması zor, ama işte gerçekten yeni bir varyant. İkiden fazla üyelik potansiyeli görüyorum, ancak aynı zamanda sadece iki üye ile en iyi kediler arasında yer alıyor.

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
   )

Dinamik kulüp üyeliği sayısı

Başka bir deyişle: değişen sayıda filtre. Bu soru tam olarak iki kulüp üyeliği istedi . Ancak birçok kullanım durumunun değişen sayılara hazırlanması gerekir.

Bu ilgili sonraki cevapta ayrıntılı tartışma:

— Erwin Brandstetter
kaynak
1
Brandstetter, Çok iyi iş. Size ekstra kredi vermek için bu soru üzerine bir ödül başlattım (ama 24 saat beklemem gerekiyor). Her neyse, sadece iki yerine birden fazla club_id eklemeye başladığınızda bu sorguların nasıl gittiğini merak ediyorum ...
— Xeoncross
@Xeoncross: Cömert hareketiniz için tebrikler. :) Daha fazla club_ids ile 1) ve 2) 'nin daha hızlı yaklaşacağından şüpheleniyorum, ancak sıralamayı alt etmek için daha büyük bir sayı olması gerekir.
— Erwin Brandstetter
Birden fazla kulübünüz varsa, bu kulüpleri içeren başka bir masa oluşturun. Ardından seçiminizde o masaya katılın.
— Paul Morgan
@Erwin: Thnx (testler için). Nitekim değil, ama belki bu sorguları (yani hepsini kastediyorum, sadece benimki değil) bir (student_id, club_id)(veya tersi) indeksle deneyebilirsiniz .
— ypercubeᵀᴹ
3
Söz konusu alan ve örneklem boyutu göz önüne alındığında, 200 ms'nin altındaki herhangi bir şeyin kabul edilebilir performans olduğunu düşünmek yanlış mı? Kişisel ilgi için, SQL Server 2008 R2 üzerinde aynı yapı indekslerini kullanarak kendi testlerimi yaptım ve (sanırım) verilerin yayılmasını ancak bir milyon öğrenciye ölçeklendirdim (verilen alan için oldukça büyük bir set olduğunu hissediyorum) ve hala yoktu Farklı yaklaşımları ayırmak için pek bir şey yok, IMO. Elbette, ilişkisel bölünmeye dayalı olanlar, onlara 'genişletilebilirlik' avantajı vererek bir temel tabloyu hedefleyebilir.
— 07
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
kaynak
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
kaynak
Bu sorgu iyi çalışıyor, ancak RDBMS'den bu kadar çok dizini * kulüp sayısını kontrol etmesini istemek zorunda kalmak beni rahatsız ediyor.
— Xeoncross
6
Bu sorguyu en çok seviyorum çünkü temiz bir stile benziyor, sql'deki python gibi. Bu tür bir kod için mutlu bir şekilde 0.44ms (Sean'ın sorgusuyla farklılık) takas ederdim.
— MGP
5

Sadece öğrenci_kimliği istiyorsanız:

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

Ayrıca öğrencinin adına da ihtiyacınız varsa:

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 )

Bir club_selection tablosunda ikiden fazla kulübünüz varsa:

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
kaynak
İlk ikisi benim sorguma dahil / aynı 1. Ama üçüncüsü @ Xeoncross'a hitap ediyor 'yukarıdaki yorumlara soru ekledi. Çiftler olmadan o kısma oy verirdim.
— Erwin Brandstetter
Yorumunuz için teşekkürler, ancak bazı biçimlendirmeler de gösteriyorum. 'Olduğu gibi' bırakacağım.
— 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)

Veya nkulüplere genişletilmesi daha kolay olan ve INTERSECT( MySQL'de mevcut değildir) ve IN( bunun MySQL'deki performansı berbat olduğundan ) daha genel bir çözüm

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
kaynak
Şüphesiz, ikinci cevabınız kod tarafından üretilen sorgular için en iyisidir. 10 kriterin ilişkisel bölümünü bulmak için ciddi olarak 10 birleştirme veya alt sorgu yazacak mıyım? Heck hayır, onun yerine bu harika çözümü kullanacağım. MySQL'de ne HAVINGolduğunu bana öğrettiğin için teşekkürler .
— Eric L.
4

Başka bir CTE. Temiz görünüyor, ancak muhtemelen normal bir alt sorguda bir groupby ile aynı planı oluşturacaktır.

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

Test etmek isteyenler için, test verileri oluşturduğum şeyin bir kopyası:

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)
    ;
— vahşi sınıf
kaynak
Evet, bu aslında ilk versiyonumdaki gibi group by ile bir alt sorgu. Aynı sorgu planı + CTE ek yükü, aynı performansla sonuçlanır + CTE için biraz. Yine de güzel bir test kurulumu.
— Erwin Brandstetter
CTE ek yükü olup olmadığını bilmiyorum. Test verilerinin dağılımı çok önemlidir. İstatistiklerin mevcudiyeti de öyle: VAKUM ANALİZİ sonrasında çalışma süresi 67,4'ten 1,56 ms'ye çıktı. Yalnızca karma ve bitmap'ler QP'ye dahil edilir.
— wildplasser
Bu sizin durumunuzda özeldir, büyük bir tablonun% 80'ini sildikten ve çok sayıda güncelleme yaptıktan sonra, her şeyden daha fazla ölü diziniz oldu. Hiç şüphe yok, vakum analizi çok yardımcı oluyor. Her iki varyantı da CTE'li ve CTE'siz çalıştırdım ve şaşırtıcı bir şekilde sorgu planları aynı değildi. veya daha iyisi, bunun için bir sohbet odası açacağım.
— Erwin Brandstetter
Merak etmeyin,% 80 ölü satırları biliyordum ... İstatistiklerin de önemli olduğunu düşünüyorum. Ancak histogram, rasgele silindiğinde oldukça 'düzdür'. Belki de planlayıcının planları değiştirmeye karar vermesine yetecek kadar değişen sadece gerekli sayfaların tahminidir.
— wildplasser
3

Yani bir kedinin derisini yüzmenin birden fazla yolu var .
Daha iyi, daha eksiksiz hale getirmek için iki tane daha ekleyeceğim .

1) Önce GRUP, sonra KATIL

Aklı başında veri modeli varsayarak (student_id, club_id)olan benzersiz olarak student_club. Martin Smith'in ikinci versiyonu biraz benzer, ancak önce gruplara daha sonra katılıyor. Bu daha hızlı olmalı:

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

Ve tabii ki klasik var EXISTS. Derek'in varyantına benzer IN. Basit ve hızlı. (MySQL'de, bu, varyantından biraz daha hızlı olmalıdır 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
kaynak
3

Bu (klasik) sürümü kimse eklemediğinden:

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

veya benzeri:

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

Biraz farklı bir yaklaşımla bir kez daha deneyin. Explain Extended'daki bir makaleden esinlenilmiştir : Bir EAV tablosundaki birden çok özellik: 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  
              )
      )

Başka bir yaklaşım:

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ᵀᴹ
kaynak
+1 .. o kadar da eksiksiz olmayan catskin koleksiyonuna güzel eklemeler! :) Ben bunları kıyaslamaya ekledim.
— Erwin Brandstetter
Bu adil bir mücadele değil :) Bölen gibi ilişkisel bir bölmenin en büyük avantajı temel bir tablo olabilir, böylelikle bölenin değiştirilmesi çok ucuzdur, yani SQL'i değiştirerek aynı sorgu tarafından hedeflenen bir temel tablodaki satırları güncelleme her seferinde sorgu.
— gün
@ErwinBrandstetter: Testlerinize 3. varyasyonu eklemek mümkün olabilir mi?
— ypercubeᵀᴹ
@ypercube: Anladın. Oldukça bükülmüş versiyon. :)
— Erwin Brandstetter
1
@Erwin: Bu biraz zaman harcamak yönetmek, ayrıca hem iki EŞSİZ Keys sahip deneyebilir (stud_id, club_id)ve (club_id, stud_id)(veya Primer ve benzersiz)? Hala bu sorgulardan bazıları için 2 ila 140 ms arasındaki farkın, yürütme planlarındaki farklılıklarla açıklanamayacak kadar yüksek olduğunu düşünüyorum.
— 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 taraması iki ayrı alt sorgu ihtiyacını ortadan kaldırdığından, bu oldukça iyi performans gösteriyor gibi görünüyor.

Yinelemeli sorguları kötüye kullanmak için her zaman bir neden vardır!

(BTW: mysql yinelemeli sorgulara sahip görünmüyor)

— vahşi sınıf
kaynak
Yine de yarı yolda daha iyi bir yol bulmak için +1! Sorgunuzu karşılaştırmaya ekledim. Umarım senin için uygundur. :)
— Erwin Brandstetter
Tamam. Ama elbette şaka amaçlıydı. Daha fazla 'başıboş' öğrenci * kulübü kaydı eklenirse CTE gerçekten iyi performans gösterir. (Test için 1000 öğrenci * 100 kulüp kullandım ve% 80 rasgele sildim)
— wildplasser
1

Sorgu 2) ve 10) 'da farklı sorgu planları

Gerçek hayatta test ettim, bu yüzden isimler catskin listesinden farklı. Bu bir yedek kopyadır, bu nedenle tüm test çalıştırmaları sırasında hiçbir şey değişmedi (kataloglardaki küçük değişiklikler hariç).

Sorgu 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

Sorgu 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
kaynak
@wildplasser: Farklı sorgu planlarına bakın! Benim için beklenmedik. sayfa 9.0. Sohbet odası beceriksizdi, bu yüzden burada bir cevabı kötüye kullanıyorum.
— Erwin Brandstetter
Tuhaf sahneler. Temelde CTE için burada aynı QP (9.0.1-beta-bir şey): dizin taraması + birleştirme yerine sıra taraması + bitmap. İyileştiricinin maliyet sezgiselindeki bir kusur olabilir mi? Başka bir CTE istismarı daha üreteceğim ...
— wildplasser
1

@ erwin-brandstetter Lütfen bunu kıyaslayın:

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 tarafından 6 numara gibi, sadece daha temiz, sanırım.

— Taai
kaynak
2
Bildirimde @bulunmanın yanıtlarda değil, yalnızca yorumlarda işe yaradığını bilmelisiniz. Bu yazıya tesadüfen rastladım. Sorgunuzun sorgu planı ve performansı, Sean'ın sorgusuyla aynıdır. Aslında aynıdır, ancak Sean'ın açık JOINsözdizimine sahip sorgusu genellikle tercih edilen biçimdir çünkü daha nettir. Yine de başka bir geçerli cevap için +1!
— 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)
    ;

Sorgu planı:

 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)

Öyleyse hala öğrenci üzerinde seq taramasını istiyor gibi görünüyor.

— vahşi sınıf
kaynak
9.1'de düzeltilip düzeltilmediğini görmek için sabırsızlanıyorum.
— 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
;

En hızlı varyantın kullanımı (Bay Brandstetter çizelgesindeki Bay Sean). Yalnızca bir katılım ile değişken olabilir, yalnızca student_club matrisinin yaşama hakkı vardır. Dolayısıyla, en uzun sorgunun hesaplanacak yalnızca iki sütunu olacak, fikir sorguyu zayıflatmaktır.

— Stepan Pavlov
kaynak
1
Bu kod parçacığı soruyu çözebilirken, bir açıklama eklemek, yayınınızın kalitesini iyileştirmeye gerçekten yardımcı olur . Sadece şimdi soran kişi değil, gelecekte okuyucular için soruyu yanıtladığınızı unutmayın! Lütfen açıklama eklemek için cevabınızı düzenleyin ve hangi sınırlamaların ve varsayımların geçerli olduğuna dair bir gösterge verin.
— BrokenBinary
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.