[英](Postgres) SQL: How to supply all missing pairs?
給定一個包含成對的“因素”和exists
標記的表:
create table pairs (
factor_1 text,
factor_2 text,
exists boolean
);
和以下數據(用於分隔符的可讀性):
factor_1 | factor_2 | exists
----------+------------------
foo | one | t
foo | two | t
-----------------------------
bar | three | t
-----------------------------
baz | four | t
baz | five | t
如何創建一個視圖,以顯示給定因子集中的所有可能對:
factor_1 | factor_2 | exists
----------+------------------
foo | one | t
foo | two | t
foo | three | f
foo | four | f
foo | five | f
-----------------------------
bar | one | f
bar | two | f
bar | three | t
bar | four | f
bar | five | f
-----------------------------
baz | one | f
baz | two | f
baz | three | f
baz | four | t
baz | five | t
我想這將是可能的,以限定一個CTE /視圖,其中包含的所有不同值factor_1
,另一個包含的所有不同值factor_2
,然后取叉積和組exists
於真對於在表中找到的所有對pairs
。 是否有更優雅/有效/慣用的方法來實現相同效果?
編輯解決方案的討論:
在短時間內提出問題和得到兩個答案之間,我去實現了上面提到的解決方案。 這就是它的樣子; 它具有3個CTE和一個隱式交叉聯接:
with
p1 as ( select distinct factor_1 from pairs ),
p2 as ( select distinct factor_2 from pairs ),
p3 as ( select * from p1, p2 )
select
p3.factor_1 as factor_1,
p3.factor_2 as factor_2,
( case when p.exists then true else false end ) as exists
from p3
left join pairs as p on ( p3.factor_1 = p.factor_1 and p3.factor_2 = p.factor_2 )
order by p3.factor_1, p3.factor_2;
現在,讓我們將其與答案進行比較。 我進行了一些重新格式化和重命名,以使所有解決方案僅在重要的地方有所不同。
Gordon Linoff的解決方案A相當短,並且不需要CTE:
select
f1.factor_1 as factor_1,
f2.factor_2 as factor_2,
coalesce( p.exists, false ) as exists
from ( select distinct factor_1 from pairs ) as p1
cross join ( select distinct factor_2 from pairs ) as p2
left join pairs p
on p.factor_1 = p1.factor_1 and p.factor_2 = p2.factor_2
order by p1.factor_1, p2.factor_2;
Valli的解決方案B甚至短了一點。 它的洞察力在於,交叉連接的組合應該是唯一的,因此,可以將“ distinct
關鍵字排除在頂部select
:
select distinct
p1.factor_1 as factor_1,
p2.factor_2 as factor_2,
coalesce( p.exists, false ) as exists
from pairs as p1
cross join pairs as p2
left join pairs as p
on p1.factor_1 = p.factor_1 and p2.factor_2 = p.factor_2
order by p1.factor_1, p2.factor_2;
我在這里擔心的是,數據庫規划師必須更加努力地工作,以防止交叉連接被過多的重復對誇大,然后被過濾掉。 因此,我確實explain analyze
了所有三種解決方案的explain analyze
( 注意 :我刪除了order by
子句); 事實證明結果有些矛盾。 我的CTE解決方案由於CTE而變得不好。 我確實在SQL中使用了很多它們,因為它們非常方便,但是它們也被稱為PostgreSQL中的優化島(類似於單獨的視圖),它顯示了。
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------
Merge Left Join (cost=4770.47..5085.69 rows=40000 width=65) (actual time=0.167..0.189 rows=15 loops=1)
Merge Cond: ((v3.factor_1 = p.factor_1) AND (v3.factor_2 = p.factor_2))
CTE v1
-> HashAggregate (cost=20.88..22.88 rows=200 width=32) (actual time=0.026..0.028 rows=3 loops=1)
Group Key: pairs.factor_1
-> Seq Scan on pairs (cost=0.00..18.70 rows=870 width=32) (actual time=0.010..0.012 rows=5 loops=1)
CTE v2
-> HashAggregate (cost=20.88..22.88 rows=200 width=32) (actual time=0.011..0.012 rows=5 loops=1)
Group Key: pairs_1.factor_2
-> Seq Scan on pairs pairs_1 (cost=0.00..18.70 rows=870 width=32) (actual time=0.003..0.005 rows=5 loops=1)
CTE v3
-> Nested Loop (cost=0.00..806.00 rows=40000 width=64) (actual time=0.044..0.062 rows=15 loops=1)
-> CTE Scan on v1 (cost=0.00..4.00 rows=200 width=32) (actual time=0.028..0.030 rows=3 loops=1)
-> CTE Scan on v2 (cost=0.00..4.00 rows=200 width=32) (actual time=0.005..0.007 rows=5 loops=3)
-> Sort (cost=3857.54..3957.54 rows=40000 width=64) (actual time=0.118..0.123 rows=15 loops=1)
Sort Key: v3.factor_1, v3.factor_2
Sort Method: quicksort Memory: 25kB
-> CTE Scan on v3 (cost=0.00..800.00 rows=40000 width=64) (actual time=0.046..0.074 rows=15 loops=1)
-> Sort (cost=61.18..63.35 rows=870 width=65) (actual time=0.042..0.042 rows=5 loops=1)
Sort Key: p.factor_1, p.factor_2
Sort Method: quicksort Memory: 25kB
-> Seq Scan on pairs p (cost=0.00..18.70 rows=870 width=65) (actual time=0.005..0.008 rows=5 loops=1)
Planning time: 0.368 ms
Execution time: 0.421 ms
(24 rows)
觀察有兩種sort
在這個計划秒。
解決方案A的計划要短得多(執行時間也很長):
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------
Hash Right Join (cost=1580.25..2499.00 rows=40000 width=65) (actual time=1.048..2.197 rows=15 loops=1)
Hash Cond: ((p.factor_1 = pairs.factor_1) AND (p.factor_2 = pairs_1.factor_2))
-> Seq Scan on pairs p (cost=0.00..18.70 rows=870 width=65) (actual time=0.010..0.015 rows=5 loops=1)
-> Hash (cost=550.25..550.25 rows=40000 width=64) (actual time=0.649..0.649 rows=15 loops=1)
Buckets: 65536 Batches: 2 Memory Usage: 513kB
-> Nested Loop (cost=41.75..550.25 rows=40000 width=64) (actual time=0.058..0.077 rows=15 loops=1)
-> HashAggregate (cost=20.88..22.88 rows=200 width=32) (actual time=0.033..0.036 rows=3 loops=1)
Group Key: pairs.factor_1
-> Seq Scan on pairs (cost=0.00..18.70 rows=870 width=32) (actual time=0.017..0.018 rows=5 loops=1)
-> Materialize (cost=20.88..25.88 rows=200 width=32) (actual time=0.008..0.011 rows=5 loops=3)
-> HashAggregate (cost=20.88..22.88 rows=200 width=32) (actual time=0.013..0.016 rows=5 loops=1)
Group Key: pairs_1.factor_2
-> Seq Scan on pairs pairs_1 (cost=0.00..18.70 rows=870 width=32) (actual time=0.004..0.006 rows=5 loops=1)
Planning time: 0.258 ms
Execution time: 2.342 ms
(15 rows)
解決方案B的執行計划比解決方案A的執行計划長得多,具有多個隱式sort
s:
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------
Unique (cost=282354.48..289923.48 rows=80000 width=65) (actual time=0.230..0.251 rows=15 loops=1)
-> Sort (cost=282354.48..284246.73 rows=756900 width=65) (actual time=0.229..0.233 rows=25 loops=1)
Sort Key: p1.factor_1, p2.factor_2, (COALESCE(p."exists", false))
Sort Method: quicksort Memory: 26kB
-> Merge Left Join (cost=140389.32..146354.17 rows=756900 width=65) (actual time=0.122..0.157 rows=25 loops=1)
Merge Cond: ((p1.factor_1 = p.factor_1) AND (p2.factor_2 = p.factor_2))
-> Sort (cost=140328.14..142220.39 rows=756900 width=64) (actual time=0.095..0.100 rows=25 loops=1)
Sort Key: p1.factor_1, p2.factor_2
Sort Method: quicksort Memory: 26kB
-> Nested Loop (cost=0.00..9500.83 rows=756900 width=64) (actual time=0.027..0.043 rows=25 loops=1)
-> Seq Scan on pairs p1 (cost=0.00..18.70 rows=870 width=32) (actual time=0.010..0.011 rows=5 loops=1)
-> Materialize (cost=0.00..23.05 rows=870 width=32) (actual time=0.003..0.005 rows=5 loops=5)
-> Seq Scan on pairs p2 (cost=0.00..18.70 rows=870 width=32) (actual time=0.005..0.008 rows=5 loops=1)
-> Sort (cost=61.18..63.35 rows=870 width=65) (actual time=0.021..0.023 rows=8 loops=1)
Sort Key: p.factor_1, p.factor_2
Sort Method: quicksort Memory: 25kB
-> Seq Scan on pairs p (cost=0.00..18.70 rows=870 width=65) (actual time=0.004..0.004 rows=5 loops=1)
Planning time: 0.260 ms
Execution time: 0.333 ms
(19 rows)
我想我們可以用這個沒有索引的簡短示例來忘記執行時間。 只有有了真實的數據,我們才能確定這些。
基於這些結果,我更喜歡Gordon Linoff的解決方案A,原因是它的SQL格式相當短,而執行計划是最簡潔的。 我對解決方案B的執行計划中可能會出現的不良性能感到有些警覺,而且我的猜測是,雖然可以將最高級別的distinct
子句排除在外,但它不一定是最精確的表達方式,盡管我很優雅。要進行交叉聯接並過濾唯一對,我想對唯一值進行交叉聯接。 不用說,萬一執行時間關系(A:2.3ms / B:0.3ms)可以顯示出具有實際數據量的數據,那將顛倒我的決定。
使用cross join
獲取行,使用left join
獲取布爾表達式:
select f1.factor_1, f2.factor_2, coalesce(p.exists, false) as exists
from (select distinct factor_1 from pairs) f1 cross join
(select distinct factor_2 from pairs) f2 left join
pairs p
on p.factor_1 = f1.factor_1 and p.factor_2 = f2.factor_2;
注意:盡管Postgres接受以列別名的形式exists
,但我認為這是一個不好的名字,因為它與SQL關鍵字沖突。
我們可以在頂部使用distinct,而不是對from子句中的distinct記錄進行過濾。 交叉聯接表,然后左聯接以獲取存在列
SELECT distinct p1.factor_1,
p2.factor_2,
coalesce(p.exists, false)
FROM pairs p1 CROSS JOIN
pairs p2 LEFT JOIN
pairs p ON
p1.factor_1= p.factor_1 and
p2.factor_2= p.factor_2
您不需要LEFT JOIN + COALESCE,因為EXISTS已經產生了一個布爾值:
SELECT f1.factor_1, f2.factor_2
, EXISTS ( SELECT* pairs p
WHERE p.factor_1 = f1.factor_1 AND p.factor_2 = f2.factor_2
) AS did_exist
FROM (SELECT DISTINCT factor_1 FROM pairs) f1
CROSS JOIN (SELECT DISTINCT factor_2 FROM pairs) f2
;
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.