我有一个具有以下规格的greenplum群集:
主服务器(16个VCPU、32 on、27 on交换空间)4个段(16个VCPU、62 on、27 on交换空间)
早些时候,我有两个段,在我的用例中表现出色,但是自从我将集群扩展到四个节点后,我就无法获得查询所使用的索引。
在10毫秒内执行的查询(索引命中)现在在顺序扫描上需要2-5秒。
我已经附加了我的模式和一些示例explain analyze输出(这是一个示例查询计划,相关表中有48260809行)。
模式:
\c dmiprod
Create Table dmiprod_schema."package"
(
identity varchar(4096) not null,
"identityHash" bytea not null,
"packageDate" date not null,
ctime timestamp not null,
customer varchar(32) not null
) distributed by ("identityHash");
ALTER TABLE ONLY dmiprod_schema.package ADD CONSTRAINT "package_pkey" PRIMARY KEY ("identityHash");
create index idx_package_ctime on dmiprod_schema.package ("ctime");
create index idx_package_packageDate on dmiprod_schema.package ("packageDate");
create index idx_package_customer on dmiprod_schema.package ("customer");
CREATE TABLE dmiprod_schema."tags"
(
"identityHash" bytea not null,
tag varchar(32) not null,
UNIQUE ("identityHash",tag)
) distributed by ("identityHash");
create index "idx_tags_identityHash" on dmiprod_schema.tags ("identityHash");
create index idx_tags_tag on dmiprod_schema.tags ("tag");
CREATE TABLE dmiprod_schema."features"
(
"identityHash" bytea not null,
ctime timestamp not null,
utime timestamp not null,
phash varchar(64) ,
ahash varchar(64),
chash varchar(78),
iimages JSON ,
lcert JSON ,
slogos JSON
) distributed by ("identityHash");
ALTER TABLE ONLY dmiprod_schema.features ADD CONSTRAINT "features_pkey" PRIMARY KEY ("identityHash");
create index idx_features_phash on dmiprod_schema.features ("phash");
CREATE TABLE dmiprod_schema."raw"
(
"identityHash" bytea not null,
ctime timestamp not null,
utime timestamp not null,
ourl TEXT,
lurl TEXT,
"pageText" TEXT,
"ocrText" TEXT,
html TEXT,
meta JSON
) distributed by ("identityHash");
ALTER TABLE ONLY dmiprod_schema.raw ADD CONSTRAINT "raw_pkey" PRIMARY KEY ("identityHash");
CREATE TABLE dmiprod_schema.packageLock
(
"identityHash" bytea not null,
secret bytea not null,
ctime timestamp not null,
UNIQUE ("identityHash")
) distributed by ("identityHash");
ALTER TABLE ONLY dmiprod_schema.packageLock ADD CONSTRAINT "packageLock_pkey" PRIMARY KEY ("identityHash");
create index idx_packageLock_secret on dmiprod_schema.packageLock ("secret");

发布于 2021-11-15 20:12:36
重新创建表和索引,在identityHash中插入2000万长度为32、48、64、96和128的随机字节,然后在使用的package_pkey中执行相同的select结果,所用时间不到20ms。
除了索引的使用之外,另一个区别是GPORCA优化器的使用。我建议您使用set optimizer = 'on';,然后重试。如果这不起作用,请发布您的GPDB/Greenplum版本和会话设置,包括优化器、enable_indexscan和任何其他相关设置。
我在VM单个物理主机和Tanzu 6.17.1上进行了测试,其中包含4个段主机。
发布于 2021-11-16 13:45:15
我只想确认一下:当您扩展系统时(假设使用gpexpand),您是否运行了重新分发阶段(gpexpand是一个分两步的过程)?完成后,您是否在系统上运行analyzedb以确保使用新的表/索引段更新了统计信息?
https://stackoverflow.com/questions/69975011
复制相似问题