语句归一化的特征值，目前有两个，分别是unique_sql_id和sql_hash，两者均是对查询树进行哈希计算之后得出的，区别在于前者是64位哈希值，后者是md5值，因此前者的重复概率会大于后者，在使用时尽量使用sql_hash进行过滤。可以看出两种方法都可以轻松获取这两个语句归一化的特征值，explain可以在事前提前获取，topsql可以在语句执行后进行获取。这个时候，可能很多小伙伴又会有疑问，语句中的条件有变化，是否会影响归一化的特征值呢？答案是不会，因为归一化过程中会去除常量的影响，上述的举例中两个语句条件中的常量值并不相同，但归一化的特征值确实一样的。由于语句的过滤，特别是关键词的正则匹配通常是比较耗时的，此时如果有过多的过滤规则，可能导致执行时间的劣化，特别是对于短查询可能影响更为明显。本地实测： 正则匹配关键词长度1024，建立查询过滤规则1000条左右时，对于查询的影响在27.72ms左右，且如果考虑其他匹配项，可能影响会更大，所以，不建议添加太多的查询过滤规则。且业务稳定后可以只对特定开发或者新业务的用户创建查询过滤规则，此时查询过滤规则会优先通过绑定的用户跳过无效的过滤，减少对性能的性能的影响。

查询语句包含了tt关键字，并且扫描的分区个数超过了2，此时执行语句被过滤拦截。需要注意的是，扫描分区的个数并不总是准确的，仅能识别静态的分区剪枝个数，执行过程中的动态剪枝并不能被识别。小技巧： 使用关键词过滤时可以先使用正则匹配符~*进行测试，正则匹配是忽略大小写的。另外，由于查询过滤器的规则直接作用在用户block_user上，因此在删除用户block_user时，会提示有依赖项，此时可以通过在语句最后加上cascade进行删除，此时作用在此用户上的查询过滤规则也会被一同删除。受限于篇幅，其他选项就不再一一列举。需要注意的是，过滤规则命中的依据是，with_parameter命中任意一项，且其他字段的特征也符合即会判定为符合查询过滤规则。特别注意，不同的计划，可能部分字段无法按照预期进行拦截。此时，语句关键字是可以匹配上的，查询的行数也超过了3行的限制，那为什么无法拦截呢？通过计划可以看出，此时是FQS计划，导致没有估算信息。因此此时无法进行拦截，对于CN轻量化的计划也是一样的，如果我们让语句强制走stream计划，那么就可以拦截成功。

DWS 不同版本支持的服务器从哪能查？之前的链接没更新是空的

单sql 偶发变慢问题定位0、## 查询锁冲突、表数据量变化select * from pgxc_lock_conflicts; -- 锁冲突 select * from pgxc_deadlock; -- 死锁 1、通过监控查看当前集群资源使用情况，是否有CPU、内存、IO 资源瓶颈通过监控、top、iostat 等方式查看系统资源情况2、通过活跃视图找出慢语句select coorname, datname, usename, client_addr, now()-query_start as dur, state, enqueue, waiting, pid, query_id, substr(replace(query, chr(10), ' '),1,150) from pgxc_stat_activity where usename not in ('omm', 'Ruby') and state <> 'idle' order by dur desc limit 100; 3、通过活跃 sql 找到对应的queryid，通过queryid 查询等待视图select * from pgxc_thread_wait_status where query_id= and wait_status not ilike '%synchronize quit%' and wait_status not ilike '%flush data%' ORDER BY node_name,tlevel; -- 单语句等待视图 SELECT wait_status,wait_event,count(*) as cnt FROM pgxc_thread_wait_status WHERE wait_status not in ('wait cmd', 'synchronize quit', 'none', 'wait stream task', 'wait node') GROUP BY 1,2 ORDER BY 3 DESC limit 100; -- 全局等待视图 SELECT node_name,wait_status,wait_event,count(*) as cnt FROM pgxc_thread_wait_status WHERE wait_status not in ('wait cmd', 'synchronize quit', 'none', 'wait stream task', 'wait node') GROUP BY 1,2,3 ORDER BY 4 DESC limit 100; -- 全局等待视图 -带节点信息 看等待视图是够有锁等待、waitio 等情况，如果等待视图出现等待某层算子时，需结合计划看慢在某层算子，稳定慢关注可能计划不好，需要 hint 固定执行计划全局等待视图如果有 waitio 则说明集群 有io 压力如果 waitio 集中在某个节点上，则关注是否倾斜、是否磁盘损坏慢盘4、通过实时topsql找到当前语句执行计划select * from pgxc_wlm_session_statistics where queryid=; 5、通过历史找到历史正常执行语句的执行计划 （postgres）库下select * from pgxc_wlm_session_info where start_time >= '2025-07-24 00:00:00' and finish_time <= '2025-07-24 23:59:59' order by duration limit 10; 6、对比执行计划，看执行计划是否跳变select * from pg_object where object_oid = 'xxx'::regclass; -- 查询表最后 analyze 时间 如果跳变则通过 analyze 进行统计信息收集，收集完，手动执行 explain verbose + sql 看计划是否恢复7、如果计划无异常、排查表膨胀以及列存表小 CU 问题select * from PGXC_GET_STAT_ALL_TABLES where relname = ；-- 脏页问题 -- 小CU 问题排查 select * from pgxc_get_small_cu_info('cdm.dws_rpt_store_goods_sale_stock_query_df'); select * from get_col_cu_info('cdm','dws_rpt_store_goods_sale_stock_query_df'); 8、定时定期对表小批量插入、更新、delete 表进行 vacuum full 操作8 级锁，阻塞业务 分区表可以针对分区进行 vacuum full 操作 VACUUM FULL tpcds.web_returns_p1 PARTITION(P2); 9、集群整体需关注问题9.1 表倾斜select schemaname,tablename,sum(dnsize)/1024^3 dnsize_gb,(max(dnsize) - avg(dnsize))*100/nullif(max(dnsize),0) skewness_factor from ( select schemaname ,tablename ,(regexp_split_to_array(tbl_dis,'[\,\(\)]+'))[4]::bigint as vprocname ,(regexp_split_to_array(tbl_dis,'[\,\(\)]+'))[5]::bigint as dnsize from ( select nspname as schemaname ,relname as tablename ,table_distribution(nspname,relname)::text as tbl_dis from pg_class a inner join pg_namespace b on a.relnamespace = b.oid and a.relkind = 'r' and b.oid not in (100) ) ) where schemaname= 'kpi' and tablename = 'dwr_testing_vehicle_kpi_d' group by 1,2 order by 3 desc; schemaname= ‘kpi’ and tablename = ‘dwr_testing_vehicle_kpi_d’9.2 大表脏页9.3 列存表小CU9.4 分区表语句不走分区剪枝9.5 不下推

DWS 不同版本支持那些jdbc URL连接参数？如jdbc:postgresql://10.10.0.13:25308/postgres?currentSchema=test的currentSchema对应开源版本支持connectTimeout, socketTimeout但是DWS不支持，有哪些参数是支持在连接串中配置的？

问题原点查sql执行时间较慢explain analyseselect * from a.bwhere data_time >= '2025-11-26 00:00:00' and data_time <= '2025-11-26 23:559:59' and id = '911221441502800';分析打执行计划analyse进行分析QUERY PlANid|Operaton|A-time|A-rows|E-rows|Peak Memory|E-memory|A-width------------------------------------------------------------------------------1|->Row Adapter    |7009.173  |  672丨 2083 | 377K8 2|    ->Vector Streaming (type: GATHER) |   7008.273  |  672丨 2083 | 2019KB3|        ->Vector Partition Iterator  |  [80.898,6985.116]丨672 | 2083 |  [16kb,16kb]  | 1MB4|            ->Partitioned  CStore Scan on a.b  | (80.802, 6983.967)]  |  672丨 2083 | [8MB,26MB] |15MB查询当前table表定义，分布键为run_id，分区键为data_time，查询条件为id，该查询中由data_time筛选到某个分区后，由id再次进行数据筛选时，筛选到的这部分数据倾斜，观察table已建立id的二级分区。继续观察执行计划 ，耗时集中在scan hstore delta,该算子从delta表中取数。hstore_opt表中的delta表用途为解决1、小批量数据入库导致小CU问题；2、以及对列存表更新/删除导致列存表膨胀问题。在执行多次小批量插入后，delta merge将数据从delta表存储转到hstore_opt表中，delta表空间会正常得到回收。现网实际业务场景，实时数据入库速度远大于delta merge速度，delta merge无法及时回收delta表空间，就出现delta表膨胀，进一步影响查询性能。Plan Node id: 3 Track name: coordinator handle data from all connections(actual time=[1.274, 1.274], calls=[60, 60])Plan Node id: 6  Track name: load CU description(actual time=[86.899, 111.336], calls=[125367, 125815])Plan Node id: 6  Track name: min/max check(actual time=[22.734, 30.065], calls=[2062, 2080])Plan Node id: 6 Track name: fill vector batch(actual time=[3401.005, 4123.678], calls=[121274, 121701])Plan Node id: 6  Track name: get CU data(actual time=[2739.232, 3461.872], calls=[242548, 243402])Plan Node id: 6  Track name: uncompress CU data(actual time=[1254.232, 1514.954], calls=[4074, 4110])Plan Node id: 6  Track name: apply projection and filter  (actual time=[10568.756, 10981.310], calls=[242249,243080])Plan Nore id: 6 Track name: scan hstore delta(actual time=[1007.184, 12737.321], calls=[2083, 2129])Plan Nore id: 6 Track name: fill later vetor batch(actual time=[13.639, 17.033], calls=[121274, 121701])Plan Node id: 6  Track name: heap scan read buffer    (sample time=[13.043, 1147.751],    estimated time=[130.470, 11477.527]...解决方案使用hstore_full_merge进行手动merge

问题       同一个SQL、同样的数据量，配置了定时任务，运行一段时间后脚本没法执行了或执行时间成指数增长、最终运行超时失败分析对比执行成功与未执行成功的执行计划。此处分析的是27号凌晨1点发起的成功查询的执行计划，与27号早9点发起的未成功查询出结果执行一段时间后被停止的失败执行计划。观察到执行失败的执行计划（下称失败计划）的36号算子与执行成功的执行计划（下称成功计划）的43号算子出现差别，此处为dnb表进行m表关联：类似于select * from dnb,m where dnb.area_code=m.area_code and dnb.run_id=m.fun_id.成功计划做了hash right join，可以看到此时优化器判断小表是45号算子也就是m表，故将m表的area_code与fun_id在内存中建立哈希表，然后扫描较大的表也就是dnb表，去探测哈希表m表，找到与散列匹配的行。失败计划做了sonic hash join，是一种优化后的Inner Join，此时优化器判断37号算子也就是dnb表为小表。失败计划的inner join错误判断将大表dnb做了内表。36    ->Vetor Sonic Hash Join(37,38) (cost=695225.73...6310390.15 rows=28378940 width=46)        Hash Cond:((dnb.area_code = m.area_code) AND (dnb.run_id=m.fun_id))        Generate Bloom Filter On Expr:m.area_code, m.fun_id               Generate Bloom Filter On Index: 0, 1               Generate Runtime Filter Type: MinMax, MinMax---------------------------------分界，以上是失败sql，以下是成功sql-----------------43    ->Vector Hash Right Join (44,45)(cost=759485.18...8206060.95 rows=83208991 width=46) (actual time=[2069.824,5826.664]...        Hach Cond ((dnb.run_id=m.fun_if) AND (dnb.area_code=m.area_code))        Generate Bloom Filter On Expr:m.fun_id, m.area_code               Generate Bloom Filter On Index: 0,1                  Generate Runtime Filter Type: MinMax, MinMax        Max Memory Used : 315268KB        Min Memory Used : 314900KB查询dnb与m表两次关联存在区别的原因，查询两表最后的analyse时间，两张表的analyse时间为null，也就是从未被执行过auto analyse,及从未被收集过执行计划。查看两表数量，都为5000w条数据，且业务反馈两表时间每次变化数据量不大。因触发auto analyse的条件是变化数据量的10%，优化器、认为数据特征未有变化，故一直未收集统计信息。统计信息不准导致优化器生成执行计划时对数据进行采样，每次采样到的数据不一致导致执行计划存在差别。故执行时间不一样。查询analyse收集时间select * from pg_stat_get_last_analyze_time('dnb'::regclass);---------------------------pg_stat_get_last_analyzenull select * from pg_stat_get_last_analyze_time('m'::regclass);---------------------------pg_stat_get_last_analyzenull 结论多表关联时，错误的统计信息，会使得大表做内表，可能导致无法全部加载进而数据下盘。      现网问题的根本原因为数据变化较少->统计信息未收集->优化器每次生成的执行计划存在差别->偶发生成不匹配的执行计划导致查询过长。 补充：有时候给出解决方法比找出原因更难，因为遇到这种问题大概率就是大表做了内表，但原因呢，藏得很深。

问题       同一个SQL、同样的数据量，配置了定时任务，运行一段时间后脚本没法执行了或执行时间成指数增长、最终运行超时失败分析对比执行成功与未执行成功的执行计划。此处分析的是27号凌晨1点发起的成功查询的执行计划，与27号早9点发起的未成功查询出结果执行一段时间后被停止的失败执行计划。观察到执行失败的执行计划（下称失败计划）的36号算子与执行成功的执行计划（下称成功计划）的43号算子出现差别，此处为dnb表进行m表关联：类似于select * from dnb,m where dnb.area_code=m.area_code and dnb.run_id=m.fun_id.成功计划做了hash right join，可以看到此时优化器判断小表是45号算子也就是m表，故将m表的area_code与fun_id在内存中建立哈希表，然后扫描较大的表也就是dnb表，去探测哈希表m表，找到与散列匹配的行。失败计划做了sonic hash join，是一种优化后的Inner Join，此时优化器判断37号算子也就是dnb表为小表。失败计划的inner join错误判断将大表dnb做了内表。36    ->Vetor Sonic Hash Join(37,38) (cost=695225.73...6310390.15 rows=28378940 width=46)        Hash Cond:((dnb.area_code = m.area_code) AND (dnb.run_id=m.fun_id))        Generate Bloom Filter On Expr:m.area_code, m.fun_id               Generate Bloom Filter On Index: 0, 1               Generate Runtime Filter Type: MinMax, MinMax---------------------------------分界，以上是失败sql，以下是成功sql-----------------43    ->Vector Hash Right Join (44,45)(cost=759485.18...8206060.95 rows=83208991 width=46) (actual time=[2069.824,5826.664]...        Hach Cond ((dnb.run_id=m.fun_if) AND (dnb.area_code=m.area_code))        Generate Bloom Filter On Expr:m.fun_id, m.area_code               Generate Bloom Filter On Index: 0,1                  Generate Runtime Filter Type: MinMax, MinMax        Max Memory Used : 315268KB        Min Memory Used : 314900KB查询dnb与m表两次关联存在区别的原因，查询两表最后的analyse时间，两张表的analyse时间为null，也就是从未被执行过auto analyse,及从未被收集过执行计划。查看两表数量，都为5000w条数据，且业务反馈两表时间每次变化数据量不大。因触发auto analyse的条件是变化数据量的10%，优化器、认为数据特征未有变化，故一直未收集统计信息。统计信息不准导致优化器生成执行计划时对数据进行采样，每次采样到的数据不一致导致执行计划存在差别。故执行时间不一样。查询analyse收集时间select * from pg_stat_get_last_analyze_time('dnb'::regclass);---------------------------pg_stat_get_last_analyzenull select * from pg_stat_get_last_analyze_time('m'::regclass);---------------------------pg_stat_get_last_analyzenull 结论多表关联时，错误的统计信息，会使得大表做内表，可能导致无法全部加载进而数据下盘。      现网问题的根本原因为数据变化较少->统计信息未收集->优化器每次生成的执行计划存在差别->偶发生成不匹配的执行计划导致查询过长。 补充：有时候给出解决方法比找出原因更难，因为遇到这种问题大概率就是大表做了内表，但原因呢，藏得很深。

1、分析              原sql如下#原sqlselect * from a.b where data_time >= '2025-11-12 00:00:00' and data_time <= '2025-11-12 23:59:59' and id = '1233333';查询sql执行计划，耗时5s，最长耗时集中在cstore scan，即列存表底层数据查询。QUERY PlANid|Operaton|A-time|A-rows|E-rows|Peak Memory|E-memory|A-width------------------------------------------------------------------------------1|->Row Adapter    |7009.173  |  672丨 2083 | 377K8 2|    ->Vector Streaming (type: GATHER) |   7008.273  |  672丨 2083 | 2019KB3|        ->Vector Partition Iterator  |  [80.898,6985.116]丨672 | 2083 |  [16kb,16kb]  | 1MB4|            ->Partitioned  CStore Scan on a.b  | (80.802, 6983.967)]  |  672丨 2083 | [8MB,26MB] |15MB继续观察详细执行计划，fill later vector batch耗时4s,该算子的含义是从宽表中填充数据，及从宽表中select *。如果把select *修改为select 必要列，该算子耗时会减少。同时观察到查询中存在计算倾斜，查询时间较短的dn耗时7ms，但查询时间较长的dn耗时4480ms。Plan Node id:4 Track name:fill later vector batchdn_6001_6002(time=7.913 total calls=81 loops=1) dn_6005_6006(time=157.372 total calls=57 loops=1)dn_6007_6008(time=49.778 total calls=61 loops=1)dn_6009_6010(time=4480.398 total calls=84 loops=1)dn_6023_6024(time=9.027 total calls=55 loops=1) 2、结论查询时间的主要耗时在fill later vector batch，该算子的含义是从宽表中填充数据。1、  计算倾斜导致数据分布不平均，个别dn计算时间过长导致整体时间较长； 即id筛选的数据在dn上倾斜。查看表倾斜，未出现倾斜，即：分布键与id筛选列具有强相关性，分布键未将id数据打散至各dn，建议重新选择分布键，将id均匀打散到各dn。2、 查询中使用了select *，导致填充数据较多，从而耗时较长。

物联网技术未来发展趋势如何？

导出数据cid:link_6计划诊断cid:link_7共享自定义数据源cid:link_0IAM用户导出按钮权限配置cid:link_8新增目录cid:link_1数据开发设置cid:link_9sql_dialect插件实现SQL自由兼容cid:link_2不可定义IMMUTABLE的几种情况cid:link_10下推属性cid:link_3入参含NULL处理cid:link_4如何写出性能最优的函数cid:link_11函数内设置GUC变量优化cid:link_12函数变更cid:link_13查询过滤器cid:link_5权限问题https://bbs.huaweicloud.com/forum/thread-0293199787641436055-1-1.html

对于普通用户来讲是没有创建查询过滤规则权限的，需要管理员或者管理员将权限赋给某一普通用户才可以。建议创建查询过滤规则时尽量缩小适用范围，避免误过滤，或者范围过大导致性能劣化。对于查询过滤规则的备份或者恢复的权限与操作元数据的权限一致，需要管理员或者管理员讲权限赋值给某一普通用户才可以，用户可以通过gs_dump导出查询过滤规则定义。如果想查看或者导入查询过滤规则的定义，可以通过pg_get_blockruledef进行查询。所有的查询过滤规则元数据全部保存在pg_blocklists系统表中，可以通过查看系统表浏览所有的查询过滤规则。查询语句包含了tt关键字，并且扫描的分区个数超过了2，此时执行语句被过滤拦截。需要注意的是，扫描分区的个数并不总是准确的，仅能识别静态的分区剪枝个数，执行过程中的动态剪枝并不能被识别。使用关键词过滤时可以先使用正则匹配符~*进行测试，正则匹配是忽略大小写的。另外，由于查询过滤器的规则直接作用在用户block_user上，因此在删除用户block_user时，会提示有依赖项，此时可以通过在语句最后加上cascade进行删除，此时作用在此用户上的查询过滤规则也会被一同删除。需要注意的是，过滤规则命中的依据是，with_parameter命中任意一项，且其他字段的特征也符合即会判定为符合查询过滤规则。

在业务开发过程中，要想禁止对2张以上的表进行关联查询，此时可以使用DDL语句创建过滤规则：table_num指的是一个语句中出现的表的个数，此时所有查询语句不能包含有两张表以上的查询。整体逻辑就非常清楚了。用户可以提前识别烂SQL的特征，然后抽象出来，用DDL语句创建规则，后续会对查询的语句进行过滤，被规则筛选出来的便是烂SQL，执行前会报错，反之则可以正常执行。之前的查询过滤器的功能依然存在，可以保证与异常规则的联动，新版本的增强更注重规则的灵活性和功能的丰富性。查询过滤规则，可以通过DDL进行新增、删除或者修改，其语法如下：block_name： 过滤规则的名称user_name： 规则应用的对象用户host： 是规则应用的客户端IPFOR： 语句类型，支持对UPDATE/SELECT/INSERT/DELETE/MEGE INTO五种类型语句进行限制FILTER BY： 过滤方法，包含两种形式SQL： 根据关键词对语句进行正则匹配，例如表名，其长度不能超过1024，建议尽量精简TEMPLATE：sql_hash：归一化的哈希值（md5），一般不会重复，相较unique_sql_id更推荐使用。unique_sql_id：归一化的64位哈希值，重复概率较sql_hash大一些。with_parameter： 查询过滤规则选项参数，可以附加多个条件，满足其一便会匹配过滤。application_name： 客户端名称query_band： 负载标识table_num： 包含的基表个数partition_num： 扫描分区的数量estimate_row： 基表输出行数resource_pool： 切换的目标资源池，仅适用于9.1.0.200及以上max_active_num： 可并发执行的语句个数，仅适用于9.1.0.200及以上is_warning： 改变拦截行为为告警，而非默认的报错，仅适用于9.1.0.200及以上其中，user_name和FILTER BY是必选项，其他可以通过业务实际需要进行配置。

函数参数个数和类型，一旦定义，不允许变更。防止用户业务报错。函数行为也禁止前后不兼容的变更，如果必须要变，需要在内核加GUC参数进行控制。这样也造成了与内核的依赖。将新函数放入dialects目录对应的方言文件中，同时还要在升级脚本中再进行处理。通过独立C函数（少量使用内核基础函数），都可以放入插件。在插件中现有或新增的cpp中编写函数。查询过滤器在9.1.0.100之前就具备提供查询过滤功能的能力，但仅支持自动隔离反复查询被终止的查询，防止烂SQL再次执行。老版本主要面向异常熔断机制和紧急拦截场景，前者可以与异常规则联动，自动将触发异常规则的语句添加到黑名单中，后者是需要手动找到core或者引发hang的语句进行屏蔽。9.1.0.100及9.1.0.200版本对查询过滤器做了功能的改进，可以通过多维度进行烂SQL识别，功能更丰富，配置更灵活。

尽量避免在函数内部设置环境变量，SET会多CN执行，造成不必要的通信开销。VOLATILE属性的SQL语言函数会频繁访问GTM，性能差，且给GTM造成比较大的压力。因此，LANGUAGE为SQL的函数，尽量不要定义为VOLATILE。函数参数的类型和返回值类型，要严格注意。避免类型转换导致的core或结果集错误。一些常见错误：应该返回timestamptz，而返回了text。结果看似一样，实际无法使用。应该返回timestamptz，而返回了timestamp，丢失了时区，未注意到。不兼容类型的强制转换，导致C函数调用core。调用内存C函数时，需要传入timestamptz类型，却给了timestamp类型，导致时区转换错误。能自动隐式类型转换的类型，尽量只写一个函数。例如：text和timestamp都可以向timestamptz自动转换，不必每个类型都实现一个相似函数。尽量使用pg原生函数定义新函数。因为兼容性函数可能因为各种兼容性导致后期修改，从而级联导致新函数结果集不稳定。