大对象 (Large objects)

主/备模式中的临时表

复制模式中的函数等

不保证使用依赖上下文的机制所产生的数据（如 random number, transaction ID, OID, SERIAL, sequence），都会被在多个后台服务器上被正确的复制。

对于SERIAL，启用insert_lock在数据复制中很有用。insert_lock 还有助于 SELECT setval() 和 SELECT nextval()。

在 pgpool-II 2.3 或更高版本中，使用 CURRENT_TIMESTAMP,CURRENT_DATE, now()的 INSERT/UPDATE 将会被正确的复制。INSERT/UPDATE 使用 CURRENT_TIMESTAMP, CURRENT_DATE, now() 作为表的默认值时，也将会正确的复制。这通过执行时把这些函数替换成从master节点上获取的常量值来完成。然而仍有一些限制：

pgpool-II 3.1 后更高版本能够正确的处理这些情况。这样"d1"将会把明天(CURRENT_DATE + 1)作为默认值。然而当扩展的协议(例如在JDBC, PHP PDO中使用的)或者 PREPARE 被使用时，这个改进并不适用。 请注意如果列类型不是临时的，重写并不会被执行，这儿有个例子： foo bigint default (date_part('epoch'::text,('now'::text)::timestamp(3) with time zone) * (1000)::double precision)

如果你在使用 8.3 或更高的版本 PostgreSQL ，并且在 reset_query_list 中指定 DISCARD ALL，那么将在会话的末尾处删除 CREATE TEMP TABLE 创建的表。 对于8.2.x或更早的版本，退出会话时并不会删除 CREATE TEMP TABLE 创建的表。这是由于连接池的原因，从 PostgreSQL 后台的视角来看，要保持 session 处于活动状态。为避免这一点，你必须通过发出 DROP TABLE 命令显式的删除该临时表，或在事务块中使用 CREATE TEMP TABLE ... ON COMMIT DROP 语句。

Queries

下面是不能被 pgpool-II 处理的查询。

INSERT (for parallel mode)

你不能使用 DEFAULT 作为分区关键字列(partitioning key column)。例如如果表t中的列x是分区关键字列， INSERT INTO t(x) VALUES (DEFAULT); 这将是无效的。而且该值也不能使用函数。 INSERT INTO t(x) VALUES (func()); INSERT的分区值只能是常量值。 SELECT INTO 和 INSERT INTO ... SELECT 也不被支持。

UPDATE (for parallel mode)

如果分区关键字列值被更新，后台数据库的数据一致性可能会丢失。pgpool-II 并不重新分区更新的数据。

如果约束被违反时一个查询在后台数据库中引起的了一个错误，一个事务有可能不能够被回滚。

如果在 WHERE 从句中一个函数被调用，该查询可能不能够被正确的执行。例如: UPDATE branches set bid = 100 where bid = (select max(bid) from beances);

SELECT ... FOR UPDATE (for parallel mode)

如果在 WHERE 从句中一个函数被调用，该查询可能不能够被正确的执行。例如: SELECT * FROM branches where bid = (select max(bid) from beances) FOR UPDATE;

COPY (for parallel mode)

COPY BINARY 不被支持。从文件中拷贝也不被支持。只有 COPY FROM STDIN 和 COPY TO STDOUT 被支持。

ALTER/CREATE TABLE (for parallel mode)

为更新分区规则，pgpool-II 必须重启以从 System DB 读取它们。

Transaction (for parallel mode)

一个事务块里面执行的 SELECT 语句将被在一个单独的事务中执行，这有个示例： BEGIN; INSERT INTO t(a) VALUES (1); SELECT * FROM t ORDER BY a;

Views / Rules (for parallel mode)

像上面的 JOIN 将在后台数据库中执行，然后由每个后台数据库返回的结果进行合并。跨节点的 Views 和 Rules 不能够被创建。然而若连接的表的数据都在同一个节点中，一个 VIEW 能够被创建。该VIEW需要在 pgpool_catalog.dist_def 中注册。一个 col_name 和 一个 dist_def_func 也必须进行注册，它们当在视图上执行插入操作时被使用。

Functions / Triggers (for parallel mode)

同样的函数定义将在所有的后台数据库中被创建。函数内不能执行跨节点连接(Join)，不能访问其它节点的数据。

Extended Query Protocol (for parallel mode)

JDBC驱动等等所使用的扩展的查询协议不被支持。必须使用简单的查询协议。这意味着你不能使用prepared statement。

Natural Join (for parallel mode)

自然连接(Natural Join)不被支持。必须使用"ON join condition" 或 "USING (join_column)"。

USING CLAUSE (for parallel mode)

USING CLAUSE 通过查询重写过程被转换为 ON CLAUSE。这样，当在目标列表中含有"*"时，连接的列会出现两次。 这儿有个示例: =# SELECT * FROM t1 JOIN t2 USING(id); id | t | t ----+-----+------- 1 | 1st | first (1 row) 在query rewrite过程中"USING"被转换成"ON"。这样下面是生效的重写结果： =# SELECT * FROM t1 JOIN t2 ON t1.id = t2.id; id | t | id | t ----+-----+----+------- 1 | 1st | 1 | first (1 row) 注意列"t"被重复。

多字节字符 (for all modes)

pgpool-II 不会在不同的多字节字符间进行转换。client, backend 以及 System DB 之间的编码必须相同。

Multi-statement Query (for all modes)

Deadlocks (for parallel mode)

跨越多个后台数据库的死锁不能够被检测。例如: (tellers table is partitioned using the following rule) tid <= 10 --> node 0 tid >= 10 --> node 1 A) BEGIN; B) BEGIN; A) SELECT * FROM tellers WHERE tid = 11 FOR UPDATE; B) SELECT * FROM tellers WHERE tid = 1 FOR UPDATE; A) SELECT * FROM tellers WHERE tid = 1 FOR UPDATE; B) SELECT * FROM tellers WHERE tid = 11 FOR UPDATE; 在上述情况下，单个的节点不能探测到死锁，这样pgpool-II将会无限期的等待响应。该现象可出现在任何获取行级别锁(row level lock)的query中。

而且，如果一个节点上出现了一个死锁，每个节点的事务状态将不再具有一致性。这样如果死锁被探测到 pgpool-II 将终止该进程。 pool_read_kind: kind does not match between master(84) slot[1] (69)

Schemas (for parallel mode)

schema 中非 public 下的对象必须使用完整名字，如： schema.object 当路径设置如下时，pgpool-II 不能找到正确的 schema： set search_path = xxx 且 schema 名在 query 中被省略。

table name - column name(for parallel mode)

System DB

分区规则 (Partitioning Rules)

仅可在一个分区规则中定义一个分区关键字列。如同'x or y'的条件式不被支持。

环境要求 (Environment Requirements)

libpq

当前， 查询缓存 必须被手动删除。 但这不影响 基于内存的查询缓存 。基于内存的查询缓存会自动清除无效的缓存。

与pgpool的兼容性 (Compatibility with pgpool)

back to top

PCP 命令参考

PCP 命令列表

PCP 命令是UNIX命令，通过网络操作pgpool-II。

常用的命令行参数

对于所有的PCP命令有5个常用的参数。它们给出了pgpool-II的信息和认证。对于有些命令必须需要多余的参数。 例如) $ pcp_node_count 10 localhost 9898 postgres hogehoge 第1个 argument - 以秒为单位的等待时间. 如果pgpool-II在这个数量的秒内没有响应，PCP将断开连接。 第2个 argument - pgpool-II的主机名 第3个 argument - PCP 端口号 第4个 argument - PCP 用户名 第5个 argument - PCP 密码

PCP的用户名和密码必须在 $prefix/etc 目录中的 pcp.conf 中声明。 启动pgpool-II时 -F 选项可被用来指定 pcp.conf 所处的别的位置。当传递给PCP命令时，并不需要以md5格式的密码。

PCP 命令

所有的PCP命令把结果显示在标准输出中。

pcp_node_count

pcp_node_info

内部信息 (Inside information)

由于 TARGETLIST 和 WHERE 从句导致执行状态的改变

在一个基本的查询中，执行状态来自于 FROM 语句。然而，如果存在一个T ARGETLIST，WHERE 语句的执行状态能够以如下情况进行改变：

当有一个子查询

当有一个聚集函数或者标记为'P'的 TARGETLIST 含 DISTINCT

当使用的一个列不存在于 FROM 语句中一个表(数据集)中时 在这些情况下，如果初始状态是P 或 S，最终的子查询、TARGETLIST 和 WHERE 语句的执行状态是S。 在下面的例子中，当子查询使用的表的状态是P，那么最终的子查询的执行状态是P。这样 WHERE 从句获得了S状态，无论L1的状态是什么，该查询将被运行在 system DB 中。 SELECT * FROM L1-table where L1-table.column IN (SELECT * FROM P1-table); 当一个状态为'P'的 TARGETLIST 含有一个聚集函数时，为了在数据获取之后执行聚集函数，FROM语句的状态改为S。在特定的条件下将对聚集函数做一些优化。

若一个列不存在于一个表中时，也可以在一个查询中使用。例如在下面的子查询中： SELECT * FROM L1-table WHERE L1-table.col1 IN (SELECT * FROM P1-table WHERE P1-table.col = L1-table.col1); 该子查询从L1-table表中引用了L1-table.col1，含子查询的 WHERE 语句的执行状态为S。

由于 GROUP BY, HAVING, ORDER BY 和 LIMIT/OFFSET 导致执行状态的改变

执行状态是'P'的 WHERE 语句，若还存在GROUP BY, HAVING, ORDER BY 语句, 或 LIMIT/OFFSET 断言时，状态改为'S'。没有 GROUP BY 的查询从 WHERE 语句获取状态。类似的方法，若没有 HAVING 语句，将使用 GROUP BY 语句的执行状态。ORDER BY 语句和 LIMIT/OFFSET 断言具有类似的行为。

当使用 UNION, EXTRACT, 及 INTERSECT 时

UNION, EXTRACT, 及 INTERSECT 查询的状态依赖于最终左侧和右侧 SELECT 语句的状态。若左右侧的状态都是L，组合的状态是L。若二者都是P，且查询是 UNION ALL，那么组合的状态是P。其它情况最终结果都是S。

获取 SELECT 的最终执行状态

如果 SELECT 中所有语句都具有状态L，那么最终的执行状态是L。同样规则使用P。对于任何其它的组合最终状态是S。如果状态是L，若 loadbalance_mode 为 true 时负载被分布在不同的节点中，否则只被发送到 MASTER 节点上。对于状态P，将使用并行执行引擎进行并行处理。对于S，将会进入下面讲述的查询重写。

查询重写 (Query rewriting)

通过使用查询分析获取的执行状态来重写查询。下面是一个例子，P1-table具有P状态，L1-table具有L状态。 SELECT P1-table.col, L1-table.col FROM P1-table,L1-table where P1-table.col = L1-table.col order by P1-table.col; 在该查询中，由于有一个 ORDER BY 语句，状态是S。FROM 语句, WHERE 语句, 和 TARGETLIST 都为P状态，查询被重写成： SELECT P1-table.col, L1-table.col FROM dblink(select pool_parallel(SELECT P1-table.col, L1-table.col FROM P1-table,L1-table where P1-table.col = L1-table.col)) order by P1-table.col; 此处dblink传送该查询到 pgpool-II。pool_parallel 函数负责发送该查询到并行执行引擎。

在该示例中 FROM 和 WHERE 语句以及 TARGETLIST 被以并行模式执行。这不是一个真正的重写查询，只是因为想提供一个示例。 这儿有另一个例子: SELECT L1-table.col FROM L1-table WHERE L1-table.col % 2 = 0 AND L1-table.col IN (SELECT P1-table FROM P1-table) ; 在该示例中，FROM 和 WHERE 语句以及 TARGETLIST 都具有状态L。因为子查询是P状态，查询本身也为S状态。这样重写为如下： SELECT L1-table.col FROM dblink(SELECT loadbalance(SELECT L1-table.col FROM L1-table WHERE L1-table.col % 2 = 0 AND TRUE)) WHERE L1-table.col %2 = 0 AND L1-table.col IN SELECT P1-Table FROM dblink(select pool_parallel(SELECT P1-table FROM P1-table))

pool_loadbalance 是一个函数，负责分发查询到任一个节点。

为聚集函数的查询重写

对于分组查询（聚集函数和 GROUP BY），重写为了减少system DB上的负载将试图在每一个节点上执行第一次聚集。

首先，我们看看 pgpool-II 为重写都做了那些事情。

该查询的 FROM 语句具有P状态且 TARGETLIST 含有count(*)，于是重写如下： select count(*) from P1-table; -> rewrite SELECT sum(pool_c$1) as count dblink(select pool_parallel('select count(*) from P1-table')) AS pool_$1g (pool_c$1 bigint);

在如下的条件下查询就会重写为上面类似的形式。

FROM 语句具有P状态。

聚集函数(仅 count, sum, min, max, 和 avg)以及 GROUP BY 中的列存在于 target list 中。

WHERE 语句具有P状态。

仅仅使用聚集函数中定义的、HAVING 语句和 FROM 语句中的、以及 GROUP BY 中的列

并行模式一些说明

并行模式下查询分析时需要列名和类型。这样当子查询的 TARGETLIST 中含有一个表达式或函数时，就需要别名和类型(通过映射 through a cast)。 请注意如果没有为表达式或函数提供映射,默认将选择文本类型。对于count()，假定为bigint类型，对于sum()为numeric类型，对于min()/max()，如果参数是date类型，返回类型为date， 其它的假定为numeric类型。avg() 被处理为 sum()/count() (总和除以数量)。

关于并行模式的性能

下面是一个相对于执行状态的查询性能的粗略估计: 执行状态性能 L一个节点时除去pgpool-II的开销，没有性能损失，因为根本就没有并行查询 P并行处理是很快的，特别针对顺序扫描。由于扫描大表变成在几个节点上分布式存在的小表上进行并行扫描，故很容易获得加速比。 S当聚集函数可在并行方式被重写时，它们很快。 pgpool-II入门教程 已发布。