小编Jef*_*man的帖子

我innodb_buffer_pool_size在具有 12 个 CPU 内核的服务器上将其设置为 20GB。我的完整数据库是 11gb，但其中大部分是几乎从未使用过的存档表。总查询数据约为 3 gb，频繁查询的数据约为 1.25 gb。

我应该设置什么innodb_buffer_pool_instances？

1. innodb_buffer_pool_size / 总查询数据 = 6 个池实例
2. innodb_buffer_pool_size / 经常查询的数据 = 16 个池实例

通常我会选择选项 #2，但从逻辑上讲，任何时候可以使用的缓冲池数量似乎不超过 CPU 内核的总数。

设置innodb_buffer_pool_instances为超过 CPU 核数是一种浪费吗？

PostgreSQL 9.4 支持REFRESH MATERIALIZED VIEW CONCURRENTLY.

我不确定，但我认为 REFRESH 命令被 PostgreSQL 视为 DDL，并且 PostgreSQL 将所有 DDL 包装在事务中，以便并发事务无法看到其他并发事务发出的 DDL 命令的影响。

我通过打开两个事务，插入数据，然后刷新其中一个事务中的物化视图，然后查询两个事务中的物化视图来验证这一点。只有第一个事务看到更新的物化视图。

有一些边缘情况我很好奇——我尝试测试这些，但我的数据集太小，所以刷新完成得太快：

1. 如果两个事务尝试并行刷新物化视图会发生什么？这是允许的还是会抛出错误？

2. 如果允许，刷新是并行执行还是串行执行？他们会互相放慢速度吗？哪个结果最终会“获胜”？

3. 假设我有一个有很多用户的应用程序。这会产生问题，应用程序为第一个用户打开一个事务，意识到物化视图缺少一个条目，因此它在返回数据之前刷新物化视图，然后另一个用户的事务在第一次刷新完成之前出现并执行相同的操作事物。无论它们是并行的还是串行的，似乎这可能会造成临时积压效应，在刷新命令的发出速度比处理速度更快的地方迅速堆积。一旦其中一个刷新完成第一个完成，任何新事务都不会尝试刷新它，但这仍可能需要很长时间。特别是如果并发刷新彼此减慢速度，这可能会很快变得痛苦。

我在 PostgreSQL 9.4 中存储了一个典型的树结构作为邻接列表：

gear_category (
   id INTEGER PRIMARY KEY,
   name TEXT,
   parent_id INTEGER   
);

以及附加到类别的项目列表：

gear_item (
   id INTEGER PRIMARY KEY,
   name TEXT,
   category_id INTEGER REFERENCES gear_category
);

任何类别都可以附加装备物品，而不仅仅是树叶。

出于速度原因，我想预先计算有关每个类别的一些数据，我将使用这些数据来生成物化视图。

期望的输出：

speedy_materialized_view (
   gear_category_id INTEGER,
   count_direct_child_items INTEGER,
   count_recursive_child_items INTEGER
);

count_recursive_child_items是附加到当前类别或任何子类别的 GearItems 的累积数量。每个类别应占一行，任何为 0 的计数都为 0。

为了计算这个，我们需要使用递归 CTE 来遍历树：

WITH RECURSIVE children(id, parent_id) AS (
    --base case
    SELECT gear_category.id AS id, gear_category.parent_id AS parent_id
    FROM gear_category
    WHERE gear_category.id = 37  -- setting this to id includes current object …