相关疑难解决方法(0)

我们的系统写入了大量数据（一种大数据系统）。写入性能足以满足我们的需求，但读取性能真的太慢了​​。

我们所有表的主键（约束）结构都相似：

timestamp(Timestamp) ; index(smallint) ; key(integer).

一个表可以有数百万行，甚至数十亿行，而一个读请求通常是针对特定时间段（时间戳/索引）和标记的。查询返回大约 20 万行是很常见的。目前，我们每秒可以读取大约 15k 行，但我们需要快 10 倍。这是可能的，如果是，如何？

注意： PostgreSQL 是和我们的软件一起打包的，所以不同客户端的硬件是不一样的。

它是一个用于测试的虚拟机。VM 的主机是具有 24.0 GB RAM 的 Windows Server 2008 R2 x64。

服务器规范（虚拟机 VMWare）

Server 2008 R2 x64
2.00 GB of memory
Intel Xeon W3520 @ 2.67GHz (2 cores)

postgresql.conf 优化

shared_buffers = 512MB (default: 32MB)
effective_cache_size = 1024MB (default: 128MB)
checkpoint_segment = 32 (default: 3)
checkpoint_completion_target = 0.9 (default: 0.5)
default_statistics_target = 1000 (default: 100)
work_mem = 100MB (default: 1MB)
maintainance_work_mem = 256MB …

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

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

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

VACUUM通常不会将磁盘空间返回给操作系统，除非在某些特殊情况下。
从文档：

VACUUM删除表和索引中的死行版本并标记可用空间以供将来重用的标准形式。但是，它不会将空间返回给操作系统，除非在表末尾的一个或多个页面完全空闲并且可以轻松获得排他表锁的特殊情况下。相比之下，VACUUM FULL通过编写一个没有死空间的完整新版本的表文件来主动压缩表。这最大限度地减少了表的大小，但可能需要很长时间。它还需要额外的磁盘空间用于表的新副本，直到操作完成。

问题是：如何实现这个数据库状态one or more pages at the end of a table become entirely free？这可以通过 完成VACUUM FULL，但我没有足够的空间来实现它。那么还有没有其他可能呢？

我正在尝试优化我的 Postgres 9.2 数据库以加快具有日期限制的查询。

我有一个timestamp专栏，但主要是我要求某一天，所以我创建了一个timestamp用于date解析的索引：

CREATE INDEX foo_my_timestamp_idx
ON foo
USING btree
((my_timestamp::date) DESC);

现在，为了提高性能，我CLUSTER foo使用上面的索引表：

CLUSTER foo USING foo_my_timestamp_idx;

根据手册上SQL-CLUSTER，表

根据索引信息进行物理重新排序

我想知道是否会对使用表 PK 的其他查询的性能产生影响（比如说id_foo）。有什么缺点吗？

VACUUM ANALYZE VERBOSE在对一些较大的表进行重大DELETE/INSERT更改后，我们会在它们上运行“手册” 。这似乎没有问题，尽管有时表的VACUUM工作会运行数小时（有关类似问题和推理，请参阅此帖子）。

在进行更多研究后，我发现即使在运行VACUUM. 例如，以下是此响应中查询生成的一些统计信息。

-[ RECORD 50 ]--+---------------------------
relname         | example_a
last_vacuum     | 2014-09-23 01:43
last_autovacuum | 2014-08-01 01:19
n_tup           |    199,169,568
dead_tup        |    111,048,906
av_threshold    |     39,833,964
expect_av       | *
-[ RECORD 51 ]--+---------------------------
relname         | example_b
last_vacuum     | 2014-09-23 01:48
last_autovacuum | 2014-08-30 12:40
n_tup           |    216,596,624
dead_tup        |    117,224,220
av_threshold    |     43,319,375
expect_av       | *
-[ RECORD 52 ]--+---------------------------
relname         | example_c
last_vacuum     | …

我有一个表，其中包含一些基于其他表的预先计算的数据。（考虑到我必须处理的数据大小，动态计算的计算成本太高。）随着源数据的添加，我将逐步生成。（UPDATE在正常使用中我永远不需要它；部分可能会被删除和重新生成。）该表将相当大。它目前大约有 5000 万行，并且每年都会增长。

对该表的大多数查询都将通过外键 ID 列进行过滤。因此，如果该 ID 的所有行都分组到相同的页面中，它们的性能会更好。我可以通过创建索引和CLUSTER定期调用来保证磁盘上的这种排序，但这显然不太理想，因为它需要某种计划任务，根据使用情况和其他计划任务进行协调等。

但是，由于我以与我想要使用的外键相关的块的形式生成这些数据CLUSTER，因此我可以轻松地ORDER BY在INSERT命令中添加一个子句：

INSERT INTO big_table (source_table1_id,a,b,c)
SELECT
   source_table1_id,
   5 /* some formula */,
   /* ... */
FROM source_table1
JOIN source_table2 ON ...
...
WHERE ... /* some condition indicating what needs to be generated */
ORDER BY source_table1_id

这是否会影响磁盘存储顺序，将行分组为接近最小页数？如果确实如此，是否还有其他进程可能会在以后弄乱磁盘顺序？

我目前正在使用 PostgreSQL 9.3，但我想了解更新的版本以及升级。