我需要提高我的数据库性能，为了实现这一点，我启用了log我的postgresql.conf：

log_statement = 'all'
log_connections = on
log_disconnections = on

为什么我有 3 个duration输出SELECT？

2016-02-29 15:35:07 CET [3492-349] postgres@uat LOG:  execute <unnamed>: SELECT ID FROM public.document WHERE documentID is NULL AND StatusID = (SELECT ID FROM public.status WHERE status = 'New') ORDER BY PriorityID DESC, ModTime ASC FOR UPDATE LIMIT 1
2016-02-29 15:35:07 CET [3492-350] postgres@uat LOG:  duration: 31.096 ms
2016-02-29 15:35:08 CET [3494-223] postgres@uat LOG:  duration: 0.090 ms
2016-02-29 15:35:08 CET [3494-224] …

我在运行 Ubuntu 的 VPS 中运行 Postgres 9.4 服务器。它经常被杀死（一天多次）。

这是来自 dmesg

内存不足：杀死进程 1020 (postgres) 得分 64 或牺牲子进程

杀死进程 1020 (postgres) total-vm:445764kB, anon-rss:140640kB, file-rss:136092kB

如何调试导致此崩溃的原因？是长时间运行的查询或服务器的某些错误配置还是打开了大量空闲连接？

创建表的脚本

DROP TABLE IF EXISTS history;
CREATE TABLE history (
    id integer NOT NULL,
    ticket_id integer NOT NULL);
ALTER TABLE ONLY history ADD CONSTRAINT history_pkey PRIMARY KEY (id);
CREATE INDEX history_ticket_id ON history USING btree (ticket_id);
DROP TABLE IF EXISTS ticket;
CREATE TABLE ticket (
    id integer NOT NULL
);
ALTER TABLE ONLY ticket ADD CONSTRAINT ticket_pkey PRIMARY KEY (id);

虚拟数据

INSERT INTO history values (generate_series(1, 30000), generate_series(1, 30000));
ANALYZE history;

INSERT INTO ticket values (generate_series(1, 40000));
ANALYZE ticket;

使用子选择查询 …

我已经阅读了相同架构/查询的 MySQL 和 PostgreSQL 之间的性能差异。. 它是否仍然与固态硬盘的外观有关？

那篇文章说 Postgres 更适合复杂查询和子查询，而对于通过 id 和顺序扫描进行的简单查询则更差。

对于某些查询，Postgres 更糟糕/更慢，因为每个表都是一个堆，意味着没有聚集索引，意味着行没有按主键在硬盘驱动器上物理排序。因此，如果您想从 Postgres 读取大部分记录（根据我的理解，通过 id） - 如果与 MySQL 相比，这将导致许多随机 I/O 和更差的性能。

问题：

1. 但是SSD呢？Postgres 和 MySQL 的顺序读取性能是否相同？
2. 在 RDBM 中使用 SSD 而不是 HHD 是否有意义？

更新：与 Rick James 的回答有关

1. MySQL 使用Plan A和 Postgres 使用Plan B，对吗？
2. Plan A表示聚集索引，对吗？该表按 物理排序lastName + firstName。
3. Plan A在 HDD 上的性能可能比Plan B在 SSD 上更好，因此 Postgres + SSD 不是灵丹妙药。查询聚集索引需要选择MySQL，对吗？
4. 请详细了解 I/O 绑定是指哪些查询？在我的理解中any call …

我在 Amazon RDS（2vCPU，8 GB RAM）上使用 Postgres 9.5。
我使用 pganalyze 来监控我的表现。
我在数据库中有大约 20 万条记录。

在我的仪表板中，我看到以下查询的平均执行时间为 28 秒和 11 秒：

UPDATE calls SET ... WHERE calls.uuid = ?   telephonist 28035.41    0.01    100%    0.03%

UPDATE calls SET sip_error = ? WHERE calls.uuid = ? telephonist 11629.89    0.44    100%    0.69%

我已经尝试VACUUM、发现并清理了 7,670 个死行。
任何想法如何提高UPDATE性能？这是查询：

UPDATE calls SET X=Y WHERE calls.uuid = 'Z'

如何改进上述查询？我可以添加另一个字段吗？例子：

UPDATE calls SET X=Y WHERE calls.uuid = 'Z' AND calls.campaign = 'W'

该列uuid未编入索引。
https://www.tutorialspoint.com/postgresql/postgresql_indexes.htm建议不建议将索引用于 …

我希望加快单个表上的一些计算。

这是表，我相信它有超过 9300 万行，并且每天都在增长：

CREATE TABLE daily_data
(
  id serial NOT NULL,
  company_id integer NOT NULL,
  trade_date date NOT NULL,
  daily_val numeric NOT NULL,
  bbg_pulls_id integer,
  gen_qtr_end_dt_id integer,
  ern_release_date_id integer,
  wh_calc_id integer,
  CONSTRAINT daily_data_pkey PRIMARY KEY (id),
  CONSTRAINT daily_data_bbg_pulls_id_fkey FOREIGN KEY (bbg_pulls_id)
      REFERENCES bbg_pulls (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION,
  CONSTRAINT daily_data_company_id_fkey FOREIGN KEY (company_id)
      REFERENCES company (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE NO ACTION,
  CONSTRAINT daily_data_ern_release_date_id_fkey FOREIGN KEY (ern_release_date_id)
      REFERENCES ern_dt …

我在 PostgreSQL 9.6中有一个查询需要很长时间才能运行：

SELECT DISTINCT ON (gc.number)
       gc.number, gc.code, ch.client_id, ch.client_parent_id
FROM client gc, client_hierarchy ch
WHERE gc.code = ch.client_id
AND gc.number in (SELECT NUMB FROM directory
                  WHERE ACTIVE = TRUE
                  AND NUMB SIMILAR TO '(ABTR|GREW|POEW)%');

SIMILAR TO接收许多不同NUMB的作为参数。ABTR|GREW|POEW大约 3.500 多。

表定义：

CREATE TABLE directory (
    id BIGINT PRIMARY KEY NOT NULL,
    active BOOLEAN NOT NULL,
    numb VARCHAR(8),
    branch VARCHAR(20),
    city VARCHAR(50),
    modified_date TIMESTAMP NOT NULL,
    name VARCHAR(200)
);
CREATE INDEX dir_numb_index ON directory (numb); …

我正在研究多租户存储网关。

每个租户都有自己的架构——每个租户的架构是一个元架构，因此每个租户架构都是相同的。数据库交互仅通过存储过程 API 发生。存储过程层位于公共架构上。存储过程依赖于设置为 的 search_path <TENANT_SCHEMA>;public。

应用层根据公共模式中的存储过程准备语句。

我有一个用于切换租户的存储过程，如下所示：

CREATE OR REPLACE FUNCTION domains_switch(domain DOMAIN_NAME) RETURNS VOID AS $$ BEGIN
  IF EXISTS (SELECT NULL FROM public.domains WHERE domain_name = domain) THEN
    EXECUTE format('set search_path=%s,public;', domain);
  ELSE
    RAISE 'domain "%" does not exist',domain USING ERRCODE = 'AX001';
  END IF;
  RETURN; END;
$$ LANGUAGE plpgsql;

plpgsql存储过程自己管理计划，这意味着我只需要在网关中为每个后端准备一次 api 语句。我怀疑当我切换模式时存储过程的内部缓存计划无效。

我计划在网关的连接池管理中添加一个层，以最小化 search_path 开关。我的直觉正确吗？这是正确的做法吗？

在这个答案中，我解释了 SQL-89 的隐式语法。
但是我在玩的时候注意到不同的查询计划：

EXPLAIN ANALYZE
  SELECT *
  FROM (values(1)) AS t(x), (values(2)) AS g(y);

                                     QUERY PLAN                                     
------------------------------------------------------------------------------------
 Result  (cost=0.00..0.01 rows=1 width=0) (actual time=0.002..0.002 rows=1 loops=1)
 Planning time: 0.052 ms
 Execution time: 0.020 ms
(3 rows)

与此相反：

EXPLAIN ANALYZE
  SELECT *
  FROM (values(1)) AS t(x)                      
  CROSS JOIN (values(2)) AS g(y);
                                           QUERY PLAN                                           
------------------------------------------------------------------------------------------------
 Subquery Scan on g  (cost=0.00..0.02 rows=1 width=4) (actual time=0.004..0.005 rows=1 loops=1)
   ->  Result  (cost=0.00..0.01 rows=1 width=0) (actual time=0.002..0.002 rows=1 loops=1)
 Planning time: 0.075 ms
 Execution time: 0.027 …

我们有一个与世界断开连接的服务器。它是一款高端系统，具有 48GB 内存和 500GB SSD 硬盘，16 核 CPU。我们正在尝试做一个pg_restore少于 10 个表的简单数据库转储，没有二进制数据或 blob，只有简单的文本（注释系统）。但是一张表大约有200GB的数据，所以它很大。

这个数据库没有其他工作。仅此维护任务。鉴于上述配置，为此目的的最佳设置是什么？PGSQL 的文档对我帮助不大。我的具体问题是关于 wal 设置。

如果我们可以使用整个服务器来做一个pg_restore，并且这个服务器上除了 PG 之外没有其他东西，我们应该使用什么设置？这就是我们现在所拥有的：

maintenance_work_mem = 1500MB 
fsync = off
synchronous_commit = off
wal_level = minimal
full_page_writes = off
wal_buffers = 64MB
#-----  checkpoint_segments = 512
#-----  max_wal_size = (3 * checkpoint_segments) * 16MB
#-- min_wal_size = 100MB    # 80MB is the default
max_wal_size = 24576MB   # based on 512 checkpoint_segments 
max_wal_senders = 0
wal_keep_segments = 0
archive_mode = off …