Question

在将一些表从SQL Server 2008移动到Postgres后，我发现性能大幅下降，我想知道我是否错过了配置步骤，或者postgres以这种方式行事是正常的。

使用的查询是表中的一个简单SELECT。没有加入，没有订购，没有。表本身只有大约12K行。我在3台机器上试过这个：

计算机A 硬件：50GB RAM，SSD磁盘，CPU：Xeon®E5-2620v3（操作系统： Ubuntu Server 16），DBMS：Postgres 9.5
机器B 硬件：8GB RAM，Sata磁盘，CPU：Xeon E5-4640（操作系统： Ubuntu Server 12），DBMS：Postgres 9.4
计算机C 硬件：4GB RAM，IDE磁盘，CPU：Xeon E3-1220v2（操作系统： Windows Server 2008），DBMS：SQL Server 2008 R2

尽管硬件和配置存在巨大差异，但我看到的2个Postgres数据库之间的性能相似。怎么会这样？

机器查询。请注意，我要排除几何列以使用“纯”数据类型：

EXPLAIN ANALYZE VERBOSE SELECT id, "OID", type, name, orofos, xrisi_orofoy, area_sqm, 
       perimeter_m, syn1_, syn1_id, str_name, str_no, katanomh, linkc, 
       xrcode, kat, ot, use, syn, notes, "MinX", "MinY", "MaxX", "MaxY"
  FROM public."korydallos_Land_Uses";

结果：

"Seq Scan on public."korydallos_Land_Uses"  (cost=0.00..872.41 rows=12841 width=209) (actual time=0.025..13.450 rows=12841 loops=1)"
"  Output: id, "OID", type, name, orofos, xrisi_orofoy, area_sqm, perimeter_m, syn1_, syn1_id, str_name, str_no, katanomh, linkc, xrcode, kat, ot, use, syn, notes, "MinX", "MinY", "MaxX", "MaxY""
"Planning time: 0.137 ms"
"Execution time: 14.788 ms"

这是 14秒的简单选择!!跆拳道？将其与SQL Server进行比较：

Query Profile Statistics    
  Number of INSERT, DELETE and UPDATE statements    0
  Rows affected by INSERT, DELETE, or UPDATE statements 0
  Number of SELECT statements   1
  Rows returned by SELECT statements    12840
  Number of transactions    0
Network Statistics  
  Number of server roundtrips   1
  TDS packets sent from client  1
  TDS packets received from server  1040
  Bytes sent from client    1010
  Bytes received from server    2477997
Time Statistics 
  Client processing time    985
  Total execution time  1022
  Wait time on server replies   37

我对可能发生的事情感到茫然。我也尝试过：

检查死行：0
吸尘
只需查询主键（！）即可。这需要500毫秒来执行。对于我添加到选择的每一列，添加大约500多个ms 查询。

Machine A Postgres性能设置：

max_connections = 200
shared_buffers = 12800MB
effective_cache_size = 38400MB
work_mem = 32MB
maintenance_work_mem = 2GB
min_wal_size = 4GB
max_wal_size = 8GB
checkpoint_completion_target = 0.9
wal_buffers = 16MB
default_statistics_target = 500

Machine B Postgres性能设置：

max_connections = 200
shared_buffers = 128MB
#effective_cache_size = 4GB
#work_mem = 4MB
#maintenance_work_mem = 64MB
#min_wal_size = 80MB
#max_wal_size = 1GB
#checkpoint_completion_target = 0.5
#wal_buffers = -1
#default_statistics_target = 100

Postgres 中的表格定义：

CREATE TABLE public."korydallos_Land_Uses"
(
  id integer NOT NULL DEFAULT nextval('"korydallos_Land_Uses_id_seq"'::regclass),
  wkb_geometry geometry(Polygon,4326),
  "OID" integer,
  type character varying(255),
  name character varying(255),
  orofos character varying(255),
  xrisi_orofoy character varying(255),
  area_sqm numeric,
  perimeter_m numeric,
  syn1_ numeric,
  syn1_id numeric,
  str_name character varying(255),
  str_no character varying(255),
  katanomh numeric,
  linkc numeric,
  xrcode character varying(255),
  kat numeric,
  ot character varying(255),
  use character varying(255),
  syn numeric,
  notes character varying(255),
  "MinX" numeric,
  "MinY" numeric,
  "MaxX" numeric,
  "MaxY" numeric,
  CONSTRAINT "korydallos_Land_Uses_pkey" PRIMARY KEY (id)
)
WITH (
  OIDS=FALSE
);
ALTER TABLE public."korydallos_Land_Uses"
  OWNER TO root;

CREATE INDEX "sidx_korydallos_Land_Uses_wkb_geometry"
  ON public."korydallos_Land_Uses"
  USING gist
  (wkb_geometry);

编辑：删除评论中建议的不相关的SQL Server定义。保持时间，因为我认为它仍然相关。根据评论，更多信息使用：

explain (analyze, verbose, buffers, timing) SELECT id, "OID", type, name, orofos, xrisi_orofoy, area_sqm, 
       perimeter_m, syn1_, syn1_id, str_name, str_no, katanomh, linkc, 
       xrcode, kat, ot, use, syn, notes, "MinX", "MinY", "MaxX", "MaxY"
  FROM public."korydallos_Land_Uses"

结果：

"Seq Scan on public."korydallos_Land_Uses"  (cost=0.00..872.41 rows=12841 width=209) (actual time=0.019..11.207 rows=12841 loops=1)"
"  Output: id, "OID", type, name, orofos, xrisi_orofoy, area_sqm, perimeter_m, syn1_, syn1_id, str_name, str_no, katanomh, linkc, xrcode, kat, ot, use, syn, notes, "MinX", "MinY", "MaxX", "MaxY""
"  Buffers: shared hit=744"
"Planning time: 1.073 ms"
"Execution time: 12.269 ms"

PG管理员在“解释标签”中向我显示：

我如何测量14秒：

运行查询时，

PG Admin 3的状态窗口，右下角。（对于这里的巨魔说这是14.3秒）。

Answer 1

https://www.postgresql.org/docs/current/static/using-explain.html

请注意，“实际时间”值以毫秒为单位实时，

所以在你的情况下

实际时间= 0.019..11.207

表示运行查询需要11毫秒。

pgadmin“解释标签”说的相同......现在，如果你看到右下角14.3秒，它花费的时间确实是14秒（用手表测量）我认为它是网络级别或pgadmin上的一些可怕的延迟本身。尝试在psql中运行它，例如：

select clock_timestamp(); 
explain analyze select * FROM public."korydallos_Land_Uses"; 
select clock_timestamp();

这将显示服务器端的时间间隔+从psql向服务器发送命令所需的时间 - 如果仍然需要14秒 - 请与网络管理员联系，如果没有，请尝试升级pgadmin

显示数据时pgAdmin会变慢吗？

1 个答案: