相关疑难解决方法(0)

我们在 Postgres 中有一个 2.2 GB 的表，其中有 7,801,611 行。我们正在向它添加一个 uuid/guid 列，我想知道填充该列的最佳方法是什么（因为我们想NOT NULL向它添加约束）。

如果我正确理解 Postgres，更新在技术上是删除和插入，所以这基本上是重建整个 2.2 gb 表。我们还有一个奴隶在运行，所以我们不希望它落后。

有没有比编写一个随着时间慢慢填充它的脚本更好的方法？

我正在执行更新，我需要一个tstzrange变量完全相等。修改了大约 100 万行，查询需要大约 13 分钟。的结果EXPLAIN ANALYZE可以在这里看到，实际结果与查询计划器估计的结果有很大的不同。问题是索引扫描t_range期望返回单行。

这似乎与范围类型的统计信息与其他类型的统计信息的存储方式有关。pg_stats查看列的视图，n_distinct是 -1，其他字段（例如most_common_vals，most_common_freqs）为空。

但是，必须在t_range某处存储统计信息。我在 t_range 上使用 'within' 而不是完全相等的极其相似的更新需要大约 4 分钟才能执行，并且使用了完全不同的查询计划（请参阅此处）。第二个查询计划对我来说很有意义，因为将使用临时表中的每一行和历史表的很大一部分。更重要的是，查询规划器为 上的过滤器预测了近似正确的行数t_range。

的分布t_range有点不寻常。我正在使用这个表来存储另一个表的历史状态，并且对另一个表的更改在大转储中同时发生，因此没有很多不同的t_range. 以下是与 的每个唯一值对应的计数t_range：

                              t_range                              |  count  
-------------------------------------------------------------------+---------
 ["2014-06-12 20:58:21.447478+00","2014-06-27 07:00:00+00")        |  994676
 ["2014-06-12 20:58:21.447478+00","2014-08-01 01:22:14.621887+00") |   36791
 ["2014-06-27 07:00:00+00","2014-08-01 07:00:01+00")               | 1000403
 ["2014-06-27 07:00:00+00",infinity)                               |   36791
 ["2014-08-01 07:00:01+00",infinity)                               |  999753

t_range上面distinct的计数是完整的，所以基数是~3M（其中~1M会受到任一更新查询的影响）。

为什么查询 1 的性能比查询 2 …

我的问题有两个部分。

1. 有没有办法在 PostgreSQL 中指定数据库的初始大小？
2. 如果没有，当数据库随着时间的推移而增长时，您如何处理碎片？

我最近从 MSSQL 迁移到 Postgres，我们在 MSSQL 世界中创建数据库时所做的一件事是指定数据库和事务日志的初始大小。这减少了碎片并提高了性能，特别是如果事先知道数据库的“正常”大小。

我的数据库的性能随着大小的增长而下降。例如，我处理的工作负载通常需要 10 分钟。随着数据库的增长，这个时间会增加。执行 VACUUM、VACUUM FULL 和 VACUUM FULL ANALYZE 似乎不能解决问题。解决性能问题的是停止数据库，对驱动器进行碎片整理，然后进行 VACUUM FULL ANALYZE 使我的测试性能恢复到原来的 10 分钟。这让我怀疑是碎片化是导致我痛苦的原因。

我在 Postgres 中找不到任何关于保留表空间/数据库空间的参考。要么我使用了错误的术语，因此一无所获，要么在 Postgres 中有一种不同的方法来减轻文件系统碎片。

任何指针？

解决方案

提供的答案有助于确认我开始怀疑的内容。PostgreSQL 将数据库存储在多个文件中，这使得数据库可以增长而不必担心碎片化。默认行为是将这些文件与表数据一起打包，这对很少更改的表有好处，但对经常更新的表不利。

PostgreSQL 利用MVCC提供对表数据的并发访问。在此方案下，每次更新都会创建已更新行的新版本（这可能是通过时间戳或版本号，谁知道？）。旧数据不会立即删除，而是标记为删除。执行 VACUUM 操作时会发生实际删除。

这与填充因子有什么关系？表默认填充因子 100 完全填充表页，这反过来意味着表页内没有空间来保存更新的行，即更新的行将放置在与原始行不同的表页中。正如我的经验所示，这对性能不利。由于我的汇总表更新非常频繁（高达 1500 行/秒），我选择将填充因子设置为 20，即表的 20% 用于插入行数据，80% 用于更新数据。虽然这可能看起来过多，但为更新行保留的大量空间意味着更新行与原始行保持在同一页内，并且在 autovacuum 守护程序运行以删除过时行时表页未满。

为了“修复”我的数据库，我执行了以下操作。

1. 将我的汇总表的填充因子设置为 20。您可以在创建时通过将参数传递给CREATE TABLE或事后通过 ALTER TABLE 来执行此操作。我发出了以下 plpgsql 命令：ALTER TABLE "my_summary_table" SET (fillfactor = 20);
2. 发出 VACUUM FULL，因为这会写入一个全新版本的表文件，因此暗示会写入一个具有新填充因子的新表文件。

重新运行我的测试，即使数据库达到我需要的数百万行，我也没有发现性能下降。

TL;DR …

我的数据库（PostgreSQL 9.3）的一部分依赖于额外的表（例如 County、City、Town...）。我不管理这些表，它们由第三方定期更新。每次我得到一个新的完整转储，但我很难将更改推回我的数据库。

我玩过 pg_dump / restore 并遇到了一些约束问题duplicate key value violates unique constraint，cannot drop constraint ... because other objects depend on it甚至使用--disable-triggersor--clean选项。

有没有我错过的选项？我发现有一些方法可以打开/关闭约束，但我不知道这是解决这个问题的好方法还是只是一个肮脏的黑客？（我不是 DBA 专家。）老实说，我很惊讶没有简单的方法来实现这一目标。也许我已经错过了！我天真地认为我可以将 pg_restore 作为一个大事务运行并在脚本末尾检查约束。是否可以？

我有这个函数返回一组记录，我需要将这些记录保存到表中。我必须每天做一百次。

我最初的方法只是清除表中的数据并再次重新插入所有记录。

-- CLEAR MY TABLE
DELETE FROM MY_TABLE;

-- POPULATE MY TABLE WITH MY FUNCTION'S RESULT
INSERT INTO MY_TABLE (COLUMN1, COLUMN2, COLUMN3)
SELECT COLUMN1, COLUMN2, COLUMN3 
FROM MY_FUNCTION(PARAM1, PARAM2, PARAM3);

到现在为止还挺好。但是我的表有很多触发器，当函数返回数千条记录时，这种方法效率很低。

然后，我转向了这种方法：

-- CREATE A TEMPORARY TABLE
CREATE GLOBAL TEMPORARY TABLE MY_TEMP_TABLE 
(COLUMN1 TEXT, COLUMN2 TEXT, COLUMN3 TEXT);

-- POPULATE MY TEMP TABLE WITH MY FUNCTION'S RESULT
INSERT INTO MY_TEMP_TABLE (COLUMN1, COLUMN2, COLUMN3)
SELECT COLUMN1, COLUMN2, COLUMN3 
FROM MY_FUNCTION(PARAM1, PARAM2, PARAM3);

-- CREATE AN INDEX FOR HELP PERFORMANCE
CREATE …

我的 Postgres 9.5 有一个movimientos包含以下数据的表：

| id | concepto | movimiento | numero | orden |
|  1 | AJUSTE 1 |       2542 |      0 |     2 |
|  2 | APERTURA |      12541 |      0 |     1 |
|  3 | AJUSTE 2 |       2642 |      0 |     2 |
|  4 | CIERRE   |      22642 |      0 |     3 |

我需要根据orden字段对记录进行编号并将这些数字保留在numero字段中，因为我需要这些数据numero在报告中进行排序和搜索。例子：

| id | concepto | movimiento | numero | orden …

我正在对一个包含 3000 万行的表进行批量 UPSERT。该表只有两列（varchar 作为主键和整数）。首先将输入数据导入到临时表中，然后执行批量更新插入（使用 INSERT ... ON CONFLICT DO UPDATE 语句）。批量大小为 4000。

我的问题是 - 您能给我哪些性能建议？当表较小时（5-1000万条记录），性能就足够好了。对于 3000 万行，这还不够好，单批 4000 条记录持续 2 到 30 秒。

当然，我几乎没有并行执行此导入的服务，因此我使用咨询锁来同步它们（一次仅执行一个批量更新插入）。我是否应该删除咨询锁以并行执行更新插入？然后我将不得不处理死锁（并使用较小的批量大小来减少死锁机会？）。

我可以采取哪些措施来提高批量更新插入的性能？

这是我的大表：

CREATE TABLE my_big_table (
  sender VARCHAR(30) PRIMARY KEY,
  count  INTEGER NOT NULL DEFAULT 0
)
WITH (
  fillfactor = 80,
  autovacuum_vacuum_scale_factor = 0,
  autovacuum_vacuum_threshold = 40000
);

这是 UPSERT 查询：

INSERT INTO my_big_table AS MBT (sender, count)
    SELECT destination, count(*) as received_count
    FROM my_temp_table
    GROUP BY destination
ON CONFLICT (sender) DO UPDATE
    SET …

我有一个 db，它有 223 个表，我必须从其中的 10 个表中删除一些记录，每个记录都有 apprx。150 万条记录。这些表每 7 秒存储一次温度。我们决定删除所有记录，但每分钟删除第一条记录。所以现在每分钟有 8 条记录，在此过程之后，它将每分钟存储 1 条超过 3 个月的记录。

我应该通过删除并在之后完全真空还是通过截断来完成？还有一些与其中一些表相关的视图。如果我通过截断来完成，这些视图之后会起作用吗？

我有一个功能：

merge_vehicles(vid, cid, vname, reg_no, name, name_1st)

我可以在输入上多次调用它吗

(2335, 55, '246BDH', '246BDH', '811', 1),
(2336, 55, '038THX', '038THX', '831', 1),
....

该函数是一个UPSERT实现返回void. 这是一个仓库数据库（事实表）。我们有一个实时数据库，每小时可以获取 1000 多个输入。我们想使用此命令将我们的数据与新数据合并。

它是一个表函数。（我已经为我们拥有的每个表定义了类似的函数 - 即 5。）结果是，它将更新现有行（如果存在），否则插入新行。

Postgres 版本是 9.3。

函数是此处接受的答案的一个版本：

• 在 PostgreSQL 中实现 UPSERT 的惯用方式

使用PostgreSQL v10.1.2 中的存储过程，哪种方法最快或哪种更好：检查行是否存在然后更新或尝试直接更新，但可能找不到与条件匹配的行？我需要检查很多条件相同的表，表是不是“非规范化”，我进行了几次测试，有时选项 1在其他情况下更快，选项 2 ...

选项1：

IF EXISTS ( SELECT  1
FROM   public.table1 
WHERE  column1 = 'oldvalue' )
THEN
   UPDATE public.table1
   SET   column1 = 'newvalue' , date_update= .... 
   WHERE  column1 = 'oldvalue';
END IF ;

选项 2：

UPDATE public.table1
SET   column1 = 'newvalue' , date_update= ... 
WHERE  column1 = 'oldvalue';

选项 3：

perform FROM   public.table1 WHERE  column1 = 'oldvalue' ;
if found then 
   UPDATE public.table1 SET column1='newvalue', date_update = ... WHERE column1 …