12.5 创建表和发送查询

介绍了Postgres-XC以及其底层的思想之后，是时候创建我们的第一个表，看看集群将如何表现。下面的例子演示了一个简单的表。将使用id列的哈希键来分布它：

test=# CREATE TABLE t_test (id int4)

DISTRIBUTE BY HASH (id);

CREATE TABLE

test=# INSERT INTO t_test

SELECT * FROM generate_series(1, 1000);

INSERT 0 1000

一旦表被创建，我们可以给它添加数据。完成后，我们可以检查是否数据已经被正确地写入到集群中：

test=# SELECT count(*) FROM t_test;

count

-------

1000

(1 row)

不奇怪，我们在我们的表中得到了1000条数据。

这里有趣的事情是查看数据是如何被数据库引擎返回的。让我们来看看我们的查询的执行计划：

test=# explain (VERBOSE TRUE, ANALYZE TRUE,

NODES true, NUM_NODES true)

SELECT count(*) FROM t_test;

QUERY PLAN

-------------------------------------------------------

Aggregate (cost=2.50..2.51 rows=1 width=0)

(actual time=5.967..5.970 rows=1 loops=1)

Output: pg_catalog.count(*)

-> Materialize (cost=0.00..0.00 rows=0 width=0)

(actual time=5.840..5.940 rows=3 loops=1)

Output: (count(*))

->Data Node Scan (primary node count=0,

node count=3) on

"__REMOTE_GROUP_QUERY__"

(cost=0.00..0.00 rows=1000 width=0)

(actual time=5.833..5.915 rows=3 loops=1)

Output: count(*)

Node/s: node2, node3, node4

Remote query: SELECT count(*) FROM

(SELECT id FROM ONLY t_test

WHERE true) group_1

Total runtime: 6.033 ms

(9 rows)

PostgreSQL将执行一个所谓的数据节点扫描。这意味着PostgreSQL将从集群中所有相关的节点收集数据。如果您仔细观察，您可以看到，哪些查询将被推到集群内部的这些节点。重要的是，该计总数已经传送到远程节点。所有这些总数来自我们的四个将被折合成一个单一总数的节点。这种方案比简单的本地查询要复杂的多，但是，随着数据量的增长，它会是非常有益的，因为每个节点将只执行操作的一个子集。事实上，当许多东西并行执行的时候，每个节点执行操作的一个子集特别地有用。

Postgres-XC优化器可以在许多情况下把操作推到数据节点，这是很好的表现。但是，您还是应该密切关注您的执行计划，以确保您有合理的计划。