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