2

作为一个简短的前言，我是 postgresql 的新手。此外，我需要建议的 postgresql 版本是 8.1。原因是 postgresql 8.1 是 ParAccel 实现和支持的该语言的最后一个版本。

Postgresql 游标，至少在 8.1 中，对于 DML 操作（例如 UPDATE 或 INSERT）非常慢（尚未测试 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 现在有几千条记录，只有两个字段

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 秒一千条记录。

同样，这只是一个简单的更新，可以作为基于集合的操作来完成。我在这里使用它只是为了模拟游标的逐行处理。在需要逐行处理的类似实际任务情况下，在使用普通 sql 不会做或过于庞大和/或复杂的情况下，使用具有如此低处理速度的游标很简单成为不可行的选择。

我怀疑这是由于数据库引擎中的上下文切换而发生的。我的问题是是否有任何可能的解决方法（或只是某种特定的方式）来显着改善 postgresql 8.1 游标中的逐行逻辑，如果这很重要的话 - 在 ParAccel (v. 4.0) 中？

谢谢！

斯坦尼斯拉夫

4

1 回答 1

2

ParAccel 不是 PostgreSQL。这是两种不同的产品，具有不同的功能，专为不同的目的而设计。ParAccel 基于 PostgreSQL，但它利用列存储，MPP 和优化器被完全重写。碰巧他们保留了 PL 扩展（很可能是为了在某些情况下简化 ETL 的编排），但他们放弃了对它的支持。其他竞争对手，如 Vertica - 他们的产品甚至没有 pgPL 扩展。

您遇到的症状与 PostgreSQL 无关。这就是 ParAccel 不支持 pgPL/SQL 解析器的确切原因。该数据库不是为逐行处理而设计的，因为它是列式的。单个更新/插入/删除将占用与对数百万行执行相同操作一样多的资源。为什么这里需要使用 PL？只需运行更新。...并阅读有关列式数据库的更多信息。如果您需要逐行运行并且没有太多选择，ParAccel 不是您需要的合适产品。

http://en.wikipedia.org/wiki/Column-oriented_DBMS
http://www.paraccel.com/resources/resources-2.php#.UdNv0m024V0

于 2013-07-03T00:18:45.977 回答