小编Clo*_*ldo的帖子

表t有两个索引：

create table t (a int, b int);
create type int_pair as (a int, b int);
create index t_row_idx on t (((a,b)::int_pair));
create index t_a_b_idx on t (a,b);

insert into t (a,b)
select i, i
from generate_series(1, 100000) g(i)
;

ANY运算符不使用索引：

explain analyze
select *
from t
where (a,b) = any(array[(1,1),(1,2)])
;
                                            QUERY PLAN                                             
---------------------------------------------------------------------------------------------------
 Seq Scan on t  (cost=0.00..1693.00 rows=1000 width=8) (actual time=0.042..126.789 rows=1 loops=1)
   Filter: (ROW(a, b) = ANY (ARRAY[ROW(1, 1), ROW(1, 2)]))
   Rows Removed …

我正在尝试使用此命令作为 postgres 用户在 Fedora 18 中将 Postgresql 从 9.2 升级到 9.3

$ pg_upgrade -b /bin -B /usr/pgsql-9.3/bin -d /var/lib/pgsql/data -D /var/lib/pgsql/9.3/data/ -j 2 -u postgres

日志中的错误

命令："/bin/pg_ctl" -w -l "pg_upgrade_server.log" -D "/var/lib/pgsql/data" -o "-p 50432 -b -c listen_addresses='' -c unix_socket_permissions=0700 -c unix_socket_directory='/var/lib/pgsql'" start >> "pg_upgrade_server.log" 2>&1 等待服务器启动......致命：无法识别的配置参数“unix_socket_directory”......停止等待 pg_ctl：无法启动服务器

正如a_horse在评论中指出的那样，参数unix_socket_directories在 9.3 中被(plural)替换。但是正在启动的服务器版本是旧的9.2：

$ /bin/pg_ctl --version
pg_ctl (PostgreSQL) 9.2.4

有任何想法吗？

我有一个非常频繁更新的表，其中包含 2.4 亿行（并且还在增长）。每三小时插入 150 万行，删除 150 万行。当我将集群移动到 SSD 时，批量插入（使用复制）时间从 22 分钟减少到 2.3 分钟。删除时间也得到改善。我计划每两小时或每小时进行一次批量更新。

虽然现在的性能（在 SSD 之后）与更频繁的更新兼容，但我读过一些关于 SSD 死亡的恐怖故事，因为 NAND 耐久性有限加上写放大。由于 SSD 价格昂贵，我想尽可能地将它的消亡推迟到未来。因此我的问题是：在删除和随后的真空中磁盘文件到底发生了什么？我猜有两个磁盘写入，一个将行标记为已删除，另一个在清理时将其标记为可覆盖。如果不是删除和清空，而是在每次批量插入/删除时对表进行分区创建和删除表，我会尽量减少 SSD 的磨损吗？