c - 为什么 PostgreSQL 数组访问在 C 中比在 PL/pgSQL 中快得多？

Question

我有一个表架构，其中包括一个 int 数组列和一个对数组内容求和的自定义聚合函数。换句话说，给定以下内容:

CREATE TABLE foo (stuff INT[]);

INSERT INTO foo VALUES ({ 1, 2, 3 });
INSERT INTO foo VALUES ({ 4, 5, 6 });

我需要一个返回 { 5, 7, 9 } 的“求和”函数。正确运行的PL/pgSQL版本如下:

CREATE OR REPLACE FUNCTION array_add(array1 int[], array2 int[]) RETURNS int[] AS $$
DECLARE
    result int[] := ARRAY[]::integer[];
    l int;
BEGIN
  ---
  --- First check if either input is NULL, and return the other if it is
  ---
  IF array1 IS NULL OR array1 = '{}' THEN
    RETURN array2;
  ELSEIF array2 IS NULL OR array2 = '{}' THEN
    RETURN array1;
  END IF;

  l := array_upper(array2, 1);

  SELECT array_agg(array1[i] + array2[i]) FROM generate_series(1, l) i INTO result;

  RETURN result;
END;
$$ LANGUAGE plpgsql;

加上:

CREATE AGGREGATE sum (int[])
(
    sfunc = array_add,
    stype = int[]
);

对于大约 150,000 行的数据集，SELECT SUM(stuff) 需要超过 15 秒才能完成。

然后我用C重写了这个函数，如下:

#include <postgres.h>
#include <fmgr.h>
#include <utils/array.h>

Datum array_add(PG_FUNCTION_ARGS);
PG_FUNCTION_INFO_V1(array_add);

/**
 * Returns the sum of two int arrays.
 */
Datum
array_add(PG_FUNCTION_ARGS)
{
  // The formal PostgreSQL array objects:
  ArrayType *array1, *array2;

  // The array element types (should always be INT4OID):
  Oid arrayElementType1, arrayElementType2;

  // The array element type widths (should always be 4):
  int16 arrayElementTypeWidth1, arrayElementTypeWidth2;

  // The array element type "is passed by value" flags (not used, should always be true):
  bool arrayElementTypeByValue1, arrayElementTypeByValue2;

  // The array element type alignment codes (not used):
  char arrayElementTypeAlignmentCode1, arrayElementTypeAlignmentCode2;

  // The array contents, as PostgreSQL "datum" objects:
  Datum *arrayContent1, *arrayContent2;

  // List of "is null" flags for the array contents:
  bool *arrayNullFlags1, *arrayNullFlags2;

  // The size of each array:
  int arrayLength1, arrayLength2;

  Datum* sumContent;
  int i;
  ArrayType* resultArray;


  // Extract the PostgreSQL arrays from the parameters passed to this function call.
  array1 = PG_GETARG_ARRAYTYPE_P(0);
  array2 = PG_GETARG_ARRAYTYPE_P(1);

  // Determine the array element types.
  arrayElementType1 = ARR_ELEMTYPE(array1);
  get_typlenbyvalalign(arrayElementType1, &arrayElementTypeWidth1, &arrayElementTypeByValue1, &arrayElementTypeAlignmentCode1);
  arrayElementType2 = ARR_ELEMTYPE(array2);
  get_typlenbyvalalign(arrayElementType2, &arrayElementTypeWidth2, &arrayElementTypeByValue2, &arrayElementTypeAlignmentCode2);

  // Extract the array contents (as Datum objects).
  deconstruct_array(array1, arrayElementType1, arrayElementTypeWidth1, arrayElementTypeByValue1, arrayElementTypeAlignmentCode1,
&arrayContent1, &arrayNullFlags1, &arrayLength1);
  deconstruct_array(array2, arrayElementType2, arrayElementTypeWidth2, arrayElementTypeByValue2, arrayElementTypeAlignmentCode2,
&arrayContent2, &arrayNullFlags2, &arrayLength2);

  // Create a new array of sum results (as Datum objects).
  sumContent = palloc(sizeof(Datum) * arrayLength1);

  // Generate the sums.
  for (i = 0; i < arrayLength1; i++)
  {
    sumContent[i] = arrayContent1[i] + arrayContent2[i];
  }

  // Wrap the sums in a new PostgreSQL array object.
  resultArray = construct_array(sumContent, arrayLength1, arrayElementType1, arrayElementTypeWidth1, arrayElementTypeByValue1, arrayElementTypeAlignmentCode1);

  // Return the final PostgreSQL array object.
  PG_RETURN_ARRAYTYPE_P(resultArray);
}

这个版本只需要 800 毫秒就可以完成，这……好多了。

(此处转换为独立扩展:https://github.com/ringerc/scrapcode/tree/master/postgresql/array_sum)

我的问题是，为什么 C 版本快得多？我预计会有改进，但 20 倍似乎有点多。这是怎么回事？在 PL/pgSQL 中访问数组是否存在固有的缓慢问题？

我在 Fedora Core 8 64 位上运行 PostgreSQL 9.0.2。该机器是高内存四重超大型 EC2 实例。

Answer 1

为什么？

why is the C version so much faster?

PostgreSQL 数组本身就是一个非常低效的数据结构。它可以包含任何 数据类型，并且可以是多维的，因此无法进行大量优化。然而，正如您所看到的，在 C 中可以更快地处理同一个数组。

这是因为C中的数组访问可以避免PL/PgSQL数组访问中涉及的大量重复工作。看看 src/backend/utils/adt/arrayfuncs.c，array_ref。现在看看它是如何从 ExecEvalArrayRef 中的 src/backend/executor/execQual.c 调用的。它针对来自 PL/PgSQL 的每个单独的数组访问运行，正如您通过将 gdb 附加到从 select pg_backend_pid() 找到的 pid 看到的那样，在 处设置断点ExecEvalArrayRef，继续并运行您的函数。

更重要的是，在 PL/PgSQL 中，您执行的每个语句都通过查询执行器机制运行。这使得小的、廉价的语句相当慢，即使考虑到它们是预先准备好的。像这样的东西:

a := b + c

实际上是由 PL/PgSQL 执行的更像是:

SELECT b + c INTO a;

如果您将调试级别设置得足够高，附加调试器并在合适的点中断，或者使用带有嵌套语句分析的 auto_explain 模块，您就可以观察到这一点。为了让您了解当您运行许多微小的简单语句(如数组访问)时这会带来多少开销，请查看 this example backtrace。以及我的笔记。

每个 PL/PgSQL 函数调用也有很大的启动开销。它并不大，但当它被用作聚合时，它足以加起来。

C 中更快的方法

在你的情况下，我可能会像你所做的那样用 C 来完成，但我会避免在作为聚合调用时复制数组。你可以check for whether it's being invoked in aggregate context :

if (AggCheckCallContext(fcinfo, NULL))

如果是这样，使用原始值作为可变占位符，修改它然后返回它而不是分配一个新值。我将编写一个演示来验证数组是否可以很快...(更新)或不会很快，我忘记了在 C 中使用 PostgreSQL 数组是多么可怕。我们开始吧:

// append to contrib/intarray/_int_op.c

PG_FUNCTION_INFO_V1(add_intarray_cols);
Datum           add_intarray_cols(PG_FUNCTION_ARGS);

Datum
add_intarray_cols(PG_FUNCTION_ARGS)
{
    ArrayType  *a,
           *b;

    int i, n;

    int *da,
        *db;

    if (PG_ARGISNULL(1))
        ereport(ERROR, (errmsg("Second operand must be non-null")));
    b = PG_GETARG_ARRAYTYPE_P(1);
    CHECKARRVALID(b);

    if (AggCheckCallContext(fcinfo, NULL))
    {
        // Called in aggregate context...
        if (PG_ARGISNULL(0))
            // ... for the first time in a run, so the state in the 1st
            // argument is null. Create a state-holder array by copying the
            // second input array and return it.
            PG_RETURN_POINTER(copy_intArrayType(b));
        else
            // ... for a later invocation in the same run, so we'll modify
            // the state array directly.
            a = PG_GETARG_ARRAYTYPE_P(0);
    }
    else 
    {
        // Not in aggregate context
        if (PG_ARGISNULL(0))
            ereport(ERROR, (errmsg("First operand must be non-null")));
        // Copy 'a' for our result. We'll then add 'b' to it.
        a = PG_GETARG_ARRAYTYPE_P_COPY(0);
        CHECKARRVALID(a);
    }

    // This requirement could probably be lifted pretty easily:
    if (ARR_NDIM(a) != 1 || ARR_NDIM(b) != 1)
        ereport(ERROR, (errmsg("One-dimesional arrays are required")));

    // ... as could this by assuming the un-even ends are zero, but it'd be a
    // little ickier.
    n = (ARR_DIMS(a))[0];
    if (n != (ARR_DIMS(b))[0])
        ereport(ERROR, (errmsg("Arrays are of different lengths")));

    da = ARRPTR(a);
    db = ARRPTR(b);
    for (i = 0; i < n; i++)
    {
            // Fails to check for integer overflow. You should add that.
        *da = *da + *db;
        da++;
        db++;
    }

    PG_RETURN_POINTER(a);
}

并将其附加到 contrib/intarray/intarray--1.0.sql:

CREATE FUNCTION add_intarray_cols(_int4, _int4) RETURNS _int4
AS 'MODULE_PATHNAME'
LANGUAGE C IMMUTABLE;

CREATE AGGREGATE sum_intarray_cols(_int4) (sfunc = add_intarray_cols, stype=_int4);

(更正确的做法是创建 intarray--1.1.sql 和 intarray--1.0--1.1.sql 并更新 intarray.control。这只是一个快速的 hack。)

使用:

make USE_PGXS=1
make USE_PGXS=1 install

编译安装

现在DROP EXTENSION intarray;(如果你已经有了)和CREATE EXTENSION intarray;。

您现在可以使用聚合函数 sum_intarray_cols(就像您的 sum(int4[]))以及双操作数 add_intarray_cols (就像您的 array_add)。

通过专注于整数数组，一大堆复杂性消失了。在聚合情况下避免了一堆复制，因为我们可以安全地就地修改“state”数组(第一个参数)。为了保持一致，在非聚合调用的情况下，我们会得到第一个参数的副本，这样我们仍然可以就地使用它并返回它。

通过使用 fmgr 缓存查找感兴趣类型的 add 函数等，这种方法可以推广到支持任何数据类型。我对这样做不是特别感兴趣，所以如果你需要它(比如，对 NUMERIC 数组的列求和)然后......玩得开心。

同样，如果您需要处理不同的数组长度，您可能可以从上面的内容中找出该怎么做。