2

簡単な序文として、私はpostgresqlの初心者です。さらに、アドバイスが必要なpostgresqlのバージョンは8.1です。その理由は、postgresql 8.1 が、ParAccel によるこの言語の最後の実装およびサポート バージョンであるためです。

Postgresql カーソルは、少なくとも 8.1 では、UPDATE や INSERT などの DML 操作で非常に遅くなります (DELETE はテストしていませんが、同じであると想定しています)。これはデモンストレーションのための単なる例です:

create table tab_cur_DML_test (col_key int,col_dml varchar(50));

いくつかのテーブルからいくつかのレコードを入力します。

insert into tab_cur_DML_test (col_key, col_dml)
select card_id, card_no
from card_dim;

tab_cur_DML_test には、2 つのフィールドのみを持つ数千のレコードが含まれるようになりました

create or replace function fn_cursor_DML_test() returns void as
$body$
declare
    v_col_key                   card_dim.card_id%type;
    v_col_dml                   card_dim.card_no%type;
    cur                     refcursor;
    v_count_proccessed_recs         bigint := 0 ;
begin
    open cur for select card_id, card_no from card_dim;
    loop
        fetch cur into v_col_key, v_col_dml;
        if not found then exit; end if;

        update tab_cur_DML_test
        set col_dml = v_col_dml
        where col_key = v_col_key;

        v_count_proccessed_recs := v_count_proccessed_recs + 1;

        if v_count_proccessed_recs%10 = 0 then
                raise info '%', v_count_proccessed_recs;
        end if;
    end loop;

end;
$body$
language plpgsql volatile;

実行後:

select * from fn_cursor_DML_test();

速度は、30 秒あたり約 1,000 レコードであることがわかります。

繰り返しますが、これはセットベースの操作として実行できる単純な更新です。ここでは、カーソルを使用して行ごとの処理をシミュレートするためだけに使用しました。行ごとの処理が必要な同様の実際のタスクの状況では、単純な sql を使用してもうまくいかないか、そうでなければかさばりすぎたり複雑すぎたりする状況では、そのような低い処理速度でカーソルを使用するのは簡単です。実行可能なオプションではなくなります。

これは、データベース エンジンのコンテキスト スイッチが原因で発生したと思われます。私の質問は、ParAccel (v. 4.0) で、postgresql 8.1 カーソル内の行ごとのロジックを大幅に改善するための回避策 (または特定の方法) はありますか?

ありがとうございました！

スタニスラフ

4

1 に答える 1