回答編集履歴
3
修正
test
CHANGED
|
@@ -38,7 +38,7 @@
|
|
|
38
38
|
|
|
39
39
|
```
|
|
40
40
|
|
|
41
|
-
SELECT * FROM compounds WHERE compounds_id IN (SELECT ...)
|
|
41
|
+
SELECT * FROM compounds WHERE compounds_id IN (SELECT ...) AND mol @> ...
|
|
42
42
|
|
|
43
43
|
```
|
|
44
44
|
|
2
追記分に対する追記
test
CHANGED
|
@@ -27,3 +27,21 @@
|
|
|
27
27
|
|
|
28
28
|
|
|
29
29
|
外部のライブラリによって提供される演算子については、ライブラリ側でコストが過小や過大に設定されているためにコスト計算がおかしくなり不効率な実行計画が選択される事例があるようです。が、実行計画見る限りではその例には当てはまらないような気がします。
|
|
30
|
+
|
|
31
|
+
|
|
32
|
+
|
|
33
|
+
--
|
|
34
|
+
|
|
35
|
+
追記されたSQLですが、二重になってるサブクエリのうち内側はともかく外側は意味不明です。
|
|
36
|
+
|
|
37
|
+
|
|
38
|
+
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
SELECT * FROM compounds WHERE compounds_id IN (SELECT ...) WHERE mol @> ...
|
|
42
|
+
|
|
43
|
+
```
|
|
44
|
+
|
|
45
|
+
|
|
46
|
+
|
|
47
|
+
でよいでしょう。
|
1
追記
test
CHANGED
|
@@ -1,4 +1,4 @@
|
|
|
1
|
-
「改善案」とされる2番目のSQLの実行計画(画像では1番目)は単純に1番目のSQLの実行計画(画像では2番目)に`substructures`テーブルのJOINが結合されただけに見えますね。
|
|
1
|
+
「改善案」とされる2番目のSQLの実行計画(画像では1番目)は単純に1番目のSQLの実行計画(画像では2番目)に`substructures`テーブルのサブクエリの結果のJOINが結合されただけに見えますね。`substructures`の検索コストが元のクエリのコストよりも大きいので、絞込に使う意味はないですし、そうすると無意味にコストを増やしているだけになっています。
|
|
2
2
|
|
|
3
3
|
|
|
4
4
|
|
|
@@ -14,8 +14,16 @@
|
|
|
14
14
|
|
|
15
15
|
|
|
16
16
|
|
|
17
|
-
とりあえず大きな問題は、`substructures`の検索が遅すぎることです。これはおそらく`query_id`にインデックスを張れば解決するとおもいます。
|
|
17
|
+
とりあえず大きな問題は、`substructures`の検索が遅すぎることです。実行計画を見る限りではこれはおそらく`query_id`にインデックスを張れば解決するとおもいます。
|
|
18
18
|
|
|
19
19
|
|
|
20
20
|
|
|
21
21
|
あとはサブクエリを結合してるのが何となくですが気持ち悪いです。結合ではなくINで検索するとか、サブクエリを使わずにJOINするとか、いろいろ試して実行計画確認してみてください
|
|
22
|
+
|
|
23
|
+
|
|
24
|
+
|
|
25
|
+
> @>というcartridge特有の機能が一番初めに実行される仕様となっているのでしょうか？
|
|
26
|
+
|
|
27
|
+
|
|
28
|
+
|
|
29
|
+
外部のライブラリによって提供される演算子については、ライブラリ側でコストが過小や過大に設定されているためにコスト計算がおかしくなり不効率な実行計画が選択される事例があるようです。が、実行計画見る限りではその例には当てはまらないような気がします。
|