1

クエリについて助けが必要です。タスクは、あるテーブルの行を取得することです。その行の合計は別のテーブルの値になり、その逆も同様です。

例の説明:

Table 1:                                Table2:

  r_id   |    r_date   |   r_amt          p_id   |    p_date   |   p_amt    
---------+-------------+--------        ---------+-------------+--------
    1    |  2/23/2012  |   200              1    |  3/22/2012  |   450
---------+-------------+--------        ---------+-------------+--------
    2    |  3/21/2012  |   100              2    |  5/25/2012  |   530
---------+-------------+--------        ---------+-------------+--------
    3    |  4/12/2012  |   300              3    |  5/26/2012  |   700
---------+-------------+--------        ---------+-------------+--------
    4    |  4/18/2012  |   250              4    |  5/26/2012  |   40
---------+-------------+--------        ---------+-------------+--------
    5    |  5/20/2012  |   130
---------+-------------+--------
    6    |  5/21/2012  |   740
---------+-------------+--------

現在、これらのテスト データは、表 1 のいくつかの行が合計されて表 2 の 1 行になり、その逆になるような方法になっています。

1 つのテーブルのレコードの合計が他のテーブルの 1 つの行と等しくなるように、上記のデータを分析するクエリが必要です。

分析が完了すると、このような新しいテーブルにデータがフィードされます。

このテーブルを呼び出しましょうmatch

  m_id   |    tbl1     |   tbl2   | match_type
---------+-------------+----------+-----------
    1    |    1,4      |   1      |   n-1
---------+-------------+----------+-----------
    1    |    2,3,5    |   2      |   n-1
---------+-------------+----------+-----------
    1    |     6       |   3,4    |   1-n
---------+-------------+----------+-----------

現在、各テーブルの合計を計算して一時テーブルに入力し、そのテーブルと比較して上記の結果を取得しています。しかし、10 行を超えると、クエリが非常に遅くなり、開発サーバーがハングします。

Link to my test Queries

このタスクを実行する効率的な方法は何ですか?

4

1 に答える 1

2

わかりましたので、ここに大まかな答えがあります。私はそれをテストしていません。再帰的 CTE には奇妙な落とし穴がいくつかあります。パフォーマンスの調整が可能な場合もありますが、これでうまくいくかもしれません。

アルゴリズムは大まかに次のようになります。

  1. すべての行のすべての順列を生成

  2. 一方の各順列を他方の各行と比較します

最初は再帰的な CTE で行われます。2 つ目は単純な結合です。

WITH RECURSIVE table1_combos as (
     SELECT r_id as last_id, r_id::text as path, r_amt as amount
       FROM table1
  UNION ALL 
     SELECT r.r_id as last_id, p.path || ',' || r_id::text, p.amount + r_amt
       FROM table1_combos p
 CROSS JOIN table1 r
      WHERE r.r_id < p.last_id
),
RECURSIVE table2_combos AS (
     SELECT p_id as last_id, p_id::text as path, p_amt as amount
       FROM table2
  UNION ALL 
     SELECT p_id AS last_id, p.path || ',' || p_id::text, p.amount + p_amt
       FROM table2_combos p
 CROSS JOIN table2 
      WHERE p_id < p.last_id
)
SELECT c.path, p_id::text, c.amount, 'n-1' as type
  FROM table1_combos c
  JOIN table2 t ON c.amount = p_amt
UNION ALL
SELECT r_id::text, c.path, c.amount, '1-n' as type
  FROM table2_combos c
  JOIN table1 t ON r_amt = c.amount;

パフォーマンスに関する基本的な問題は、検索するスペースが大量にあることです。残念ながら、それを行うための合理的に簡単な方法はありません。組み合わせスペースは非常に大きく、行を追加するたびに大きくなります。

うーん、私の見積もりを再検討します。10 行のテーブルは 630 万の組み合わせを生成する必要があり、11 行のテーブルは 6860 万の組み合わせを生成する必要があります。PostgreSQL では、次の SQL ステートメントを使用して、予想される組み合わせの数を確認できます。

select sum(factorial(11)/factorial(f)) from generate_series(1, 11) f;

11 行テーブルの場合。次のように注意してください。

select sum(factorial(100)/factorial(f)) from generate_series(1, 100) f;

         sum                                                                    

--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
----------------------
 1603607401161831447335715093560135199544316103019165207641822220922316539151565
30909999021448995531507013709811500779735358328288932830176709764490323163992001
.00000000000000000000
(1 row)

100行のテーブルだとちょっと待ちますね……。

たとえば、「他のテーブルの最大値に達したら停止する」と言ってCTE自体を制限することで、これにさらに対処できる場合があります。

于 2013-03-11T11:57:04.387 に答える