PostgreSQL数据库的数据类型介绍PostgreSQL，作为一款功能强大的开源对象关系型数据库系统，以其丰富的数据类型、高度的可扩展性和卓越的性能受到广泛赞誉。本文将深入探讨PostgreSQL支持的主要数据类型，帮助开发者更好地理解并选择适合其应用场景的数据类型。一、数值数据类型整数类型smallint：占用2字节，范围大约从-32,768到32,767。integer（或int）：最常用的类型，占用4字节，范围大约从-2^31到2^31-1。bigint：占用8字节，适合需要更大数值范围的应用场景。浮点数类型real：单精度浮点数，占用4字节，提供约7位小数的精度。double precision：双精度浮点数，占用8字节，提供约15位小数的精度。任意精度数值类型numeric（或decimal）：用于需要高精度计算的场景，用户可以指定精度和比例。自增类型smallserial、serial、bigserial：分别为smallint、integer、bigint的自动增长版本，常用于主键。二、字符串数据类型**char(n)**：定长字符串，n指定长度，不足部分用空格填充。**varchar(n)**：变长字符串，n指定最大长度，但只存储实际字符数。text：无长度限制的文本字符串，适合存储大量文本。三、日期/时间数据类型date：存储日期，格式为YYYY-MM-DD。time：存储时间，可选带时区信息，格式HH:MM:SS[.fraction][+/-timezone]。timestamp：存储日期和时间，同样可带时区信息，精确到微秒。interval：表示时间间隔，例如'5 days 3 hours'。四、二进制数据类型bytea：用于存储二进制数据，如图片、文件等。五、布尔类型boolean：存储真/假值，即TRUE或FALSE。六、数组类型PostgreSQL支持数组数据类型，允许在单个列中存储同一类型数据的集合。七、特殊及用户自定义类型JSON和JSONB：分别用于存储非结构化数据的文本和二进制格式。XML：存储XML数据。UUID：用于存储通用唯一识别码。几何类型：如point、line、polygon等，用于地理信息系统应用。网络地址类型：如inet、cidr、macaddr，用于存储IP地址、子网等。自定义类型：通过CREATE TYPE命令，用户可以定义自己的数据类型。

1.环境准备角色主机名IP端口数据库名用户名版本发布端postgresql192.168.80.2395432pubdbreplicpostgresql 15订阅端postgresql2192.168.80.2405432subdbreplicpostgresql 152.发布端配置参数## vi postgressql.conf（重启生效） listen_addresses = '*' wal_level=logical max_replication_slots=8 max_wal_senders=10 ## alter system set alter system set wal_level=logical; ## 参数说明 wal_level设置为logical，才支持逻辑复制，低于这个级别逻辑复制不能工作。 max_replication_slots设置值必须大于订阅的数量。 max_wal_senders设置值必须大于max_replication_slots参数值加上物理备库数，因为每个订阅在主库上都会占用主库一个wal发送进程。3.发布端配置pg_hba.confvi pg_hba.conf host    replication     test       0/0         md54.订阅端配置参数## vi postgresql.conf（重启生效） listen_addresses = '*' wal_level=logical max_replication_slots=8 max_logical_replication_workers=8 ## alter system set alter system set wal_level=logical; ## 参数说明 max_replication_slots设置数据库复制槽数量。 max_logical_replication_workers设置逻辑复制进程数，应大于订阅节点的数量，并且给表同步预留一些进程数量。 注意：max_logical_replication_workers会消耗后台进程数，并且从max_worker_processes参数设置的后台进程数中消费，因此max_worker_processes需要设置的大一些。5.发布端创建逻辑复制用户，并具备replication复制权限（可选）如不创建，可以使用默认的管理员用户postgres。postgres=# create user replic replication login connection limit 8 password 'replic'; CREATE ROLE limit 8：为新用户设置最大数目连接数。默认无限制。6.发布端创建发布## 创建复制数据库 postgres=# create database pubdb; CREATE DATABASE ## 授予复制用户权限 postgres=# \c pubdb postgres You are now connected to database "pubdb" as user "postgres". pubdb=# grant all on schema public to replic; GRANT ## 创建复制表 pubdb=> create table c1 (id int4 primary key,name text); CREATE TABLE pubdb=> insert into c1 values (1,'a'); INSERT 0 1 pubdb=> select * from c1;  id | name  ----+------   1 | a (1 row) ## 创建发布 pubdb=> \c pubdb postgres You are now connected to database "pubdb" as user "postgres". pubdb=# create publication pub1 for table c1; CREATE PUBLICATION 注意：如果发布多张表使用逗号隔开，如果发布所有表则将 for table 修改为 for all tables。 ##查看创建的发布 pubdb=# select * from pg_publication;   oid  | pubname | pubowner | puballtables | pubinsert | pubupdate | pubdelete | pubtruncate | pubviaroot  -------+---------+----------+--------------+-----------+-----------+-----------+-------------+------------  33177 | pub1    |       10 | f            | t         | t         | t         | t           | f (1 row) 参数说明： pubname：发布名称。 pubowner：发布的属主，可以和pg_user视图的usesysid字段关联查询属主的具体信息。 puballtables：是否发布数据库中的所有表，t 表示发布数据库中所有已存在的表和以后新建的表。 pubinsert：t 表示仅发布表上的insert操作。 pubupdate：t 表示仅发布表上的update操作。 pubdelete：t 表示仅发布表上的delete操作。 pubtruncate：t 表示仅发布表上的truncate操作。7.发布端给复制用户授权pubdb=# grant connect on database pubdb to replic; GRANT pubdb=# grant usage on schema public to replic; GRANT pubdb=# grant select on c1 to replic; GRANT8.订阅端创建表postgres=# create database subdb; CREATE DATABASE postgres=# create user replic replication login connection limit 8 password 'replic'; CREATE ROLE subdb=> \c subdb postgres You are now connected to database "subdb" as user "postgres". subdb=# grant all on schema public to replic; GRANT subdb=> create table c1 (id int4 primary key,name text); CREATE TABLE9.订阅端创建订阅subdb=> \c subdb postgres You are now connected to database "subdb" as user "postgres". subdb=# create subscription sub1 connection 'host=192.168.80.239 port=5432 dbname=pubdb user=replic password=replic' publication pub1; NOTICE:  created replication slot "sub1" on publisher CREATE SUBSCRIPTION ## 查看创建的订阅 subdb=# \x Expanded display is on. subdb=# select * from pg_subscription; -[ RECORD 1 ]----+----------------------------------------------------------------------- oid              | 41374 subdbid          | 41361 subskiplsn       | 0/0 subname          | sub1 subowner         | 10 subenabled       | t subbinary        | f substream        | f subtwophasestate | d subdisableonerr  | f subconninfo      | host=192.168.80.239 port=5432 dbname=pubdb user=replic password=replic subslotname      | sub1 subsynccommit    | off subpublications  | {pub1}10.订阅端给复制用户授权subdb=# grant connect on database subdb to replic; GRANT subdb=# grant usage on schema public to replic; GRANT subdb=# grant select on c1 to replic; GRANT11.配置完成，发布端查看信息postgres=# select slot_name,plugin,slot_type,database,active,restart_lsn from pg_replication_slots where slot_name='sub1';  slot_name |  plugin  | slot_type | database | active | restart_lsn  -----------+----------+-----------+----------+--------+-------------  sub1      | pgoutput | logical   | pubdb    | t      | 0/3F45C840 (1 row)

我们写了一些函数/存储过程用来展现报表数据，为了存储中间数据用了临时表，并且临时表在运行过程中insert的数据量有时候会很大（百万级），因此在后续对这些临时表引用的时候，需要对这些表做动态采样，否则会导致执行计划有问题。在Oralce中，我们在函数/存储过程中在对临时表做关联查询的时候，采用 SELECT /*+ opt_param('OPTIMIZER_DYNAMIC_SAMPLING',6) */ 这样的hint 来要求做动态采样。在Opengauss中，我们先是尝试在INSERT 临时表数据后，通过ANALYZE tablename;来更新该临时表的统计信息，但是ANALYZE无法在函数/存储过程中执行，否则会报”ANALYZE cannot run inside a transaction block”。请问是否有其它办法可以在函数/存储过程中对临时表做动态采样？

Postgresql入门Postgresql数据库简介PostgresQL是一个功能强大的开源数据库系统。经过长达15年以上的积极开发和不断改进，PostgreSQL已在可靠性、稳定性、数据一致性等获得了业内极高的声誉。目前PostgreSql可以运行在所有主流操作系统上，包括Linux、Unix(AIX、BSD、HP-UX、SGIIRIX、MacOs X、Solaris和Tru64)和Windows。作为一种企业级数据库，PostgresQL以它所具有的各种高级功能而自豪，像多版本并发控制(MVCC)、按时间点恢复(PITR)、表空间、异步复制、嵌套事务、在线热备、复杂查询的规划和优化以及为容错而进行的预写日志等。它支持国际字符集、多字节编码并支持使用当地语言进行排序、大小写处理和格式化等操作。截止2024年三月份，postgresql数据库得分排名第四，且仍出现上升去世来源：cid:link_2postgresql特性极限值: 最大单个数据库大小： 不限 最大数据单表大小：32 TB 单条记录最大：1.6 TB 单字段最大允许：1 GB 单表允许最大记录数：不限 单表最大字段数：250-1600(取决于字段类型) 单表最大索引数：不限postgresql兼容性PostgreSQL对SQL标准高度兼容，它实现的功能完全遵守于ANSI-SQL:2008标准。目前完全支持子查询(包括在FROM中的子查询)、授权读取和可序列化的事务隔离级别。同时PostgreSQL也具有完整的关系数据库系统的目录功能，它支持单数据库的多模式功能，每一个目录可通过SQL标准中定义的字典信息模式进行访问。Data集成性功能包括(复合)主键、含有严格约束或级联更新和删除功能的外键、录入检查约束、唯一性约束和非空约束。PostgreSQL也具有很多扩展模块和更高级的功能。其中有为方便使用的通过序列实现的自增字段、允许返回部分记录集的LIMIT/OFFSET选项，也支持复合、唯一、部分和函数式索引，索引并支持B-Tree、R-Tree、Hash或GiST存储方式。postgresql高度可定制性PostgreSQL的存储过程开发可以使用众多的程序语言，包括Java、Perl、Python、Ruby、Tc1、C/C++和自带的PL/pgSQL，其中的PL/pgSQL与Oracle的PL/SQL很相似,内置了数百个函数，功能从基本的算术计算和字符串处理到加密逻辑计算并与0racle有高度兼容性。 由于有很多的存储过程语言可以使用，这样也产生了很多的库接口，这样允许各种编译型或是解释型的语言在PostgreSQL进行使用，包括Java(JDBC)、0DBC、Perl、Python、Ruby、C、C++、PHP、Lisp、Scheme和Qt等。 最重要的一点，PostgreSQL的源代码可以自由获取，它的授权是在非常自由的开源授权下，这种授权允许用户在各种开源或是闭源项目中使用、修改和发布PostgreSQL的源代码。用户对源代码的可以按用户意愿进行任何修改、改进。PostgreSQL部分历史大版本发布时间post-Ingres :1985年，成立该项目Postgres V1 - V4:1988年至1993年Postgres95 :1995年，重写了SQL解释器PostgreSQL 6.x:1996年，正式更名，表示Postgres + SQL，发布第一个开源版本PostgreSQL 7.1 :加入了预写式日志功能；不再限制文本类型的数据段长度PostgreSQL 8.x :对Windows平台支持；支持事务保存点、表空间、即时恢复等功能；并开始支持Perl服务器端编程语言PostgreSQL 9.0:加入流复制、Hot Standby功能PostgreSQL 9.1:加入同步流复制PostgreSQL 9.2:加入级联复制功能PostgreSQL 9.3:加入物化视图功能；支持事件触发；可写外部表PostgreSQL 9.4:逻辑复制 btre索引PostgreSQL 9.5:加入行级别安全功能，TABLESAMPLE 数据取样功能PostgreSQL 9.6:加入并行查询功能；多standby节点数据同步PostgreSQL 10: 表分区、提高并行查询性能PostgreSQL 11: 并行功能增强、分区增强、存储过程支持嵌入事务PostgreSQL 12: 在线重建索引、索引优化、流复制配置简化VersionCurrent minorSupportedFirst ReleaseFinal Release1616.2YesSeptember 14, 2023November 9, 20281515.6YesOctober 13, 2022November 11, 20271414.11YesSeptember 30, 2021November 12, 20261313.14YesSeptember 24, 2020November 13, 20251212.18YesOctober 3, 2019November 14, 20241111.22NoOctober 18, 2018November 9, 20231010.23NoOctober 5, 2017November 10, 20229.09.0.23NoSeptember 20, 2010October 8, 20158.08.0.26NoJanuary 19, 2005October 1, 20107.07.0.3NoMay 8, 2000May 8, 20056.56.5.3NoJune 9, 1999June 9, 20046.06.0.0NoMarch 1, 1998March 1, 2003postgresql学习资源官网：cid:link_4postgresql中文：cid:link_3墨天轮社区：cid:link_5引用PostgreSQL主要特性及发展里程碑事件cid:link_0postgresql入门到精通教程cid:link_1

     我最近开发了一个maven项目，想使用spark读取/写入greenplum的数据，但是由于jdbc的传输速度限制。所以想采用greenplum-spark connect这个连接器。当我使用--jars将项目和这个依赖包一起提交上去的时候出现了jar包冲突 报错:classnotfound。  同时自己搭建了一套开源集群，相同的步骤 spark读取/写入greenplum 并且也使用这个连接器--jars提供第三方依赖包，正常读取数据。    所以我想有没有办法忽略集群中的依赖。只使用fat-jar和--jar提供的      

 一个优化的SQL：   SELECT order_date,       order_source,       SUM(commodity_num) num,       SUM(actual_charge) charge   FROM (   SELECT to_char(oc.create_date, 'yyyyMMdd') AS order_date,               (CASE                 WHEN oo.event_type = 'ONLINE_COMMODITY_ORDER' THEN                   '线上'                 ELSE                   '线下'               END) order_source,               oc.commodity_num,               oc.actual_charge actual_charge           FROM ord.ord_commodity_hb_2017 AS oc, ord.ord_order_hb_2017 AS oo         WHERE oc.order_id = oo.order_id           AND oc.op_type = 3            -- 3个值 ，3->5000 大概1/20的数据           AND oc.create_date BETWEEN '2017-02-05' AND '2017-12-07' -- 无用           AND oc.corp_org_id = 106      -- 无用           AND oo.trade_state = 11        -- 3个值  11 --> 71万行，一半数据           AND oo.event_type IN (values('ONLINE_COMMODITY_ORDER'),                                 ('USER_CANCEL'),                                 ('USER_COMMODITY_UPDATE'))    -- 大概1/10 数据                                 ORDER BY oc.create_date    -- 如果业务不强制，最好去掉排序，如果不能去掉，最好等过滤数据量到尽量小时再排序                                 ) T GROUP BY order_date, order_source;      下面默认以postgresql为例：   一、排序:  1. 尽量避免  2. 排序的数据量尽量少，并保证在内存里完成排序。  （至于具体什么数据量能在内存中完成排序，不同数据库有不同的配置：      oracle是sort_area_size；      postgresql是work_mem (integer)，单位是KB，默认值是4MB。      mysql是sort_buffer_size 注意：该参数对应的分配内存是每连接独占！      ）   二、索引：  1. 过滤的数据量比较少，一般来说<20%,应该走索引。20%-40% 可能走索引也可能不走索引。> 40% ，基本不走索引(会全表扫描)  2. 保证值的数据类型和字段数据类型要一直。  3. 对索引的字段进行计算时，必须在运算符右侧进行计算。也就是 to_char(oc.create_date, 'yyyyMMdd')是没用的  4. 表字段之间关联，尽量给相关字段上添加索引。  5. 复合索引，遵从最左前缀的原则,即最左优先。（单独右侧字段查询没有索引的）    三、连接查询方式：  1、hash join   放内存里进行关联。  适用于结果集比较大的情况。  比如都是200000数据   2、nest loop   从结果1 逐行取出，然后与结果集2进行匹配。  适用于两个结果集，其中一个数据量远大于另外一个时。  结果集一：1000  结果集二：1000000   四、多表联查时：  在多表联查时，需要考虑连接顺序问题。      1、当postgresql中进行查询时，如果多表是通过逗号，而不是join连接，那么连接顺序是多表的笛卡尔积中取最优的。如果有太多输入的表， PostgreSQL规划器将从穷举搜索切换为基因概率搜索，以减少可能性数目(样本空间)。基因搜索花的时间少， 但是并不一定能找到最好的规划。           2、对于JOIN，          LEFT JOIN / RIGHT JOIN 会一定程度上指定连接顺序，但是还是会在某种程度上重新排列：          FULL JOIN 完全强制连接顺序。          如果要强制规划器遵循准确的JOIN连接顺序，我们可以把运行时参数join_collapse_limit设置为 1         五、PostgreSQL提供了一些性能调优的功能：   优化思路：      0、为每个表执行 ANALYZE <table>。然后分析 EXPLAIN (ANALYZE，BUFFERS) sql。      1、对于多表查询，查看每张表数据，然后改进连接顺序。      2、先查找那部分是重点语句，比如上面SQL，外面的嵌套层对于优化来说没有意义，可以去掉。      3、查看语句中，where等条件子句，每个字段能过滤的效率。找出可优化处。          比如oc.order_id = oo.order_id是关联条件，需要加索引          oc.op_type = 3 能过滤出1/20的数据，          oo.event_type IN (...) 能过滤出1/10的数据，          这两个是优化的重点，也就是实现确保op_type与event_type已经加了索引，其次确保索引用到了。   优化方案：   a) 整体优化：  1、使用EXPLAIN    EXPLAIN命令可以查看执行计划，这个方法是我们最主要的调试工具。   2、及时更新执行计划中使用的统计信息         由于统计信息不是每次操作数据库都进行更新的，一般是在 VACUUM 、 ANALYZE 、 CREATE INDEX等DDL执行的时候会更新统计信息，   因此执行计划所用的统计信息很有可能比较旧。 这样执行计划的分析结果可能误差会变大。  以下是表tenk1的相关的一部分统计信息。   SELECT relname, relkind, reltuples, relpages FROM pg_class WHERE relname LIKE 'tenk1%';        relname                  | relkind | reltuples | relpages ----------------------+---------+-----------+----------   tenk1                            | r      |    10000 |      358   tenk1_hundred              | i      |    10000 |      30   tenk1_thous_tenthous    | i      |    10000 |      30   tenk1_unique1              | i      |    10000 |      30   tenk1_unique2              | i        |    10000 |      30 (5 rows)  其中 relkind是类型，r是自身表，i是索引index；reltuples是项目数；relpages是所占硬盘的块数。   估计成本通过 （磁盘页面读取【relpages】*seq_page_cost）+（行扫描【reltuples】*cpu_tuple_cost）计算。  默认情况下， seq_page_cost是1.0，cpu_tuple_cost是0.01。  名字    类型    描述 relpages    int4    以页(大小为BLCKSZ)的此表在磁盘上的形式的大小。 它只是规划器用的一个近似值，是由VACUUM,ANALYZE 和几个 DDL 命令，比如CREATE INDEX更新。 reltuples    float4    表中行的数目。只是规划器使用的一个估计值，由VACUUM,ANALYZE 和几个 DDL 命令，比如CREATE INDEX更新。 3、使用临时表（with）  对于数据量大，且无法有效优化时，可以使用临时表来过滤数据，降低数据数量级。   4、对于会影响结果的分析，可以使用 begin;...rollback;来回滚。    b) 查询优化：  1、明确用join来关联表，确保连接顺序    一般写法：SELECT * FROM a, b, c WHERE a.id = b.id AND b.ref = c.id;    如果明确用join的话，执行时候执行计划相对容易控制一些。  例子：      SELECT * FROM a CROSS JOIN b CROSS JOIN c WHERE a.id = b.id AND b.ref = c.id;      SELECT * FROM a JOIN (b JOIN c ON (b.ref = c.id)) ON (a.id = b.id);   c) 插入更新优化  1、关闭自动提交（autocommit=false）  如果有多条数据库插入或更新等，最好关闭自动提交，这样能提高效率   2、多次插入数据用copy命令更高效    我们有的处理中要对同一张表执行很多次insert操作。这个时候我们用copy命令更有效率。因为insert一次，其相关的index都要做一次，比较花费时间。   3、临时删除index【具体可以查看Navicat表数据生成sql的语句，就是先删再建的】    有时候我们在备份和重新导入数据的时候，如果数据量很大的话，要好几个小时才能完成。这个时候可以先把index删除掉。导入后再建index。   4、外键关联的删除    如果表的有外键的话，每次操作都没去check外键整合性。因此比较慢。数据导入后再建立外键也是一种选择。    d) 修改参数：  选项    默认值    说明    是否优化    原因 max_connections    100    允许客户端连接的最大数目    否    因为在测试的过程中，100个连接已经足够 fsync    on    强制把数据同步更新到磁盘    是    因为系统的IO压力很大，为了更好的测试其他配置的影响，把改参数改为off shared_buffers    24MB    决定有多少内存可以被PostgreSQL用于缓存数据（推荐内存的1/4)    是    在IO压力很大的情况下，提高该值可以减少IO work_mem    1MB    使内部排序和一些复杂的查询都在这个buffer中完成    是    有助提高排序等操作的速度，并且减低IO effective_cache_size    128MB    优化器假设一个查询可以用的最大内存，和shared_buffers无关（推荐内存的1/2)    是    设置稍大，优化器更倾向使用索引扫描而不是顺序扫描 maintenance_work_mem    16MB    这里定义的内存只是被VACUUM等耗费资源较多的命令调用时使用    是    把该值调大，能加快命令的执行 wal_buffer    768kB    日志缓存区的大小    是    可以降低IO，如果遇上比较多的并发短事务，应该和commit_delay一起用 checkpoint_segments    3    设置wal log的最大数量数（一个log的大小为16M）    是    默认的48M的缓存是一个严重的瓶颈，基本上都要设置为10以上 checkpoint_completion_target    0.5    表示checkpoint的完成时间要在两个checkpoint间隔时间的N%内完成    是    能降低平均写入的开销 commit_delay    0    事务提交后，日志写到wal log上到wal_buffer写入到磁盘的时间间隔。需要配合commit_sibling    是    能够一次写入多个事务，减少IO，提高性能 commit_siblings    5    设置触发commit_delay的并发事务数，根据并发事务多少来配置    是    减少IO，提高性能 autovacuum_naptime    1min    下一次vacuum任务的时间    是    提高这个间隔时间，使他不是太频繁 autovacuum_analyze_threshold    50    与autovacuum_analyze_scale_factor配合使用，来决定是否analyze    是    使analyze的频率符合实际 autovacuum_analyze_scale_factor    0.1    当update,insert,delete的tuples数量超过autovacuum_analyze_scale_factor*table_size+autovacuum_analyze_threshold时，进行analyze。    是    使analyze的频率符合实际  下面介绍几个我认为重要的：  1、增加maintenance_work_mem参数大小    增加这个参数可以提升CREATE INDEX和ALTER TABLE ADD FOREIGN KEY的执行效率。   2、增加checkpoint_segments参数的大小    增加这个参数可以提升大量数据导入时候的速度。   3、设置archive_mode无效    这个参数设置为无效的时候，能够提升以下的操作的速度    ・CREATE TABLE AS SELECT    ・CREATE INDEX    ・ALTER TABLE SET TABLESPACE    ・CLUSTER等。   4、autovacuum相关参数  autovacuum：默认为on，表示是否开起autovacuum。默认开起。特别的，当需要冻结xid时，尽管此值为off，PG也会进行vacuum。   autovacuum_naptime：下一次vacuum的时间，默认1min。 这个naptime会被vacuum launcher分配到每个DB上。autovacuum_naptime/num of db。   log_autovacuum_min_duration：记录autovacuum动作到日志文件，当vacuum动作超过此值时。 “-1”表示不记录。“0”表示每次都记录。   autovacuum_max_workers：最大同时运行的worker数量，不包含launcher本身。   autovacuum_work_mem    ：每个worker可使用的最大内存数。  autovacuum_vacuum_threshold    ：默认50。与autovacuum_vacuum_scale_factor配合使用， autovacuum_vacuum_scale_factor默认值为20%。当update,delete的tuples数量超过autovacuum_vacuum_scale_factor*table_size+autovacuum_vacuum_threshold时，进行vacuum。如果要使vacuum工作勤奋点，则将此值改小。   autovacuum_analyze_threshold        ：默认50。与autovacuum_analyze_scale_factor配合使用。  autovacuum_analyze_scale_factor    ：默认10%。当update,insert,delete的tuples数量超过autovacuum_analyze_scale_factor*table_size+autovacuum_analyze_threshold时，进行analyze。   autovacuum_freeze_max_age：200 million。离下一次进行xid冻结的最大事务数。   autovacuum_multixact_freeze_max_age：400 million。离下一次进行xid冻结的最大事务数。   autovacuum_vacuum_cost_delay    ：如果为-1，取vacuum_cost_delay值。   autovacuum_vacuum_cost_limit       ：如果为-1，到vacuum_cost_limit的值，这个值是所有worker的累加值。       原文：https://blog.csdn.net/qq_40026782/article/details/109221038?spm=1001.2014.3001.5502 

.net windows 开发好了，都是通的，linux环境发布之后为什么连不上数据库了 ？ 装上了linux的驱动 但还是一直找不到文件  是开发的链接字符串也要改嘛

摘要 本文将带您深入了解PostgreSQL（简称PG）的世界，这是一种功能强大、开源的关系型数据库管理系统。我们将讨论它的历史、特性、为什么选择它，以及如何进行性能优化。通过本文，读者将能够更好地理解并应用PostgreSQL，以满足各种业务需求。一、PostgreSQL的历史与概述 PostgreSQL起源于加州大学伯克利分校的POSTGRES项目，该项目始于1986年，目标是创建一个具有扩展性的关系型数据库管理系统。经过多年的发展，PostgreSQL已经成为一个功能齐全、性能卓越、稳定可靠的数据库解决方案，广泛应用于各种业务场景。二、PostgreSQL的主要特性开源与社区支持 作为一个开源项目，PostgreSQL拥有庞大的开发者社区，这意味着用户可以受益于持续的更新、修复和改进。此外，开源特性使得企业可以根据自身需求进行定制，提高灵活性。扩展性 PostgreSQL具有良好的扩展性，支持用户自定义函数、操作符和类型。这使得它可以轻松地适应各种业务需求，包括空间数据、全文搜索和时间序列等。数据完整性与安全性 PostgreSQL提供了ACID事务支持，确保数据的完整性和一致性。同时，它支持SSL加密、行级安全性以及多种身份验证方法，保障数据的安全性。性能与可伸缩性 通过优化查询、索引设计、并行处理和分区等功能，PostgreSQL可以实现高性能的数据处理。此外，它支持多种存储引擎和硬件架构，具有良好的可伸缩性。三、为什么选择PostgreSQL？成本效益 作为一个开源项目，PostgreSQL无需购买许可证，降低了企业的成本。同时，由于其强大的功能和性能，可以减少硬件和运维成本。灵活性与可扩展性 PostgreSQL的开源和扩展性使得企业可以根据自身需求进行定制，提高系统的灵活性。同时，它支持各种存储引擎和硬件架构，易于扩展。数据安全性与完整性 PostgreSQL提供了强大的数据安全性和完整性保障，使得企业可以放心地存储和处理敏感数据。社区支持与生态系统 PostgreSQL拥有活跃的开发者社区和丰富的生态系统，这意味着遇到问题时可以快速找到解决方案，同时可以享受各种工具和插件带来的便利。四、PostgreSQL的性能优化策略 为了充分发挥PostgreSQL的性能优势，以下是一些建议的优化策略：硬件和系统配置优化 确保服务器具备足够的内存、CPU和存储资源以支持预期的负载。合理配置操作系统的参数和网络连接可以提高数据库的性能。使用高性能的存储设备和配置RAID阵列可以提高I/O性能和数据可靠性。为PostgreSQL分配足够的内存可以提高缓存效率并减少磁盘I/O操作。使用多核处理器可以提高并行处理能力并加速复杂查询的执行速度。优化网络连接可以减少网络延迟和带宽限制对数据库性能的影响。使用高速、低延迟的网络连接可以提高数据传输效率并降低网络瓶颈的风险。合理设置数据库的工作内存和维护工作内存参数可以平衡内存使用和查询性能之间的关系。根据系统资源和负载特点调整共享缓冲区、有效缓存大小和日志缓冲区等关键参数可以显著提高数据库的性能和稳定性。通过调整检查点频率和日志写入策略来平衡数据持久性和性能之间的关系是非常重要的。根据实际需求和数据量大小来制定合适的日志设置策略以避免日志写入成为性能瓶颈。通过监控数据库性能指标如查询响应时间、资源利用率和错误日志等来及时发现并解决潜在的性能问题是非常重要的。使用专业的监控工具或自定义脚本可以帮助您实时掌握数据库的运行状态并进行相应的调整和优化操作。定期对数据库进行维护操作如清理无用数据、重建索引和优化查询等可以保持数据库的高效运行状态并预防潜在的性能问题发生。

摘要本文旨在深入探讨PostgreSQL（简称PG）数据库性能调优的各个方面。我们将引导读者了解调优的重要性，分析性能瓶颈，探索硬件和系统配置对性能的影响，并详细介绍查询优化、索引设计和数据库参数调整等关键调优技术。通过深入理解这些概念和实践技巧，读者将能够显著提高PG数据库的性能，从而满足高负载、低延迟的业务需求。一、引言在当今数据驱动的时代，数据库已成为企业应用程序的核心组件。PostgreSQL作为一种功能强大、开源的关系型数据库管理系统（RDBMS），广泛应用于各种业务场景。然而，随着数据量的增长和业务复杂度的提高，数据库性能问题日益凸显。为了解决这些问题，我们需要深入了解PG数据库性能调优的艺术。二、性能调优的重要性性能调优对于确保数据库在高负载下保持高效、稳定和可扩展至关重要。以下是性能调优的几个主要好处：提高响应时间：通过减少查询执行时间和优化资源使用，使用户能够更快地获取所需数据。增加吞吐量：通过优化查询和存储结构，使数据库能够处理更多的并发请求。降低成本：通过更有效的资源利用，减少不必要的硬件升级和扩展需求。改进用户体验：通过确保数据库在高负载下保持稳定，提高用户满意度和忠诚度。三、性能瓶颈分析在开始调优之前，首先需要识别和解决性能瓶颈。以下是一些常见的性能问题及其可能的原因：慢查询：可能是由于缺少索引、不合适的查询设计或不足的硬件资源导致的。高磁盘I/O：可能是由于不恰当的存储配置、不足的缓冲区大小或频繁的磁盘操作引起的。高CPU使用率：可能是由于复杂的查询、不足的内存或低效的算法造成的。锁争用：可能是由于高并发访问、不恰当的隔离级别或不足的锁资源导致的。四、硬件和系统配置调优1. 存储系统选择高性能的存储设备（如SSD）和配置RAID阵列可以提高I/O性能和数据可靠性。此外，合理分布数据和日志文件可以减少I/O争用。2. 内存增加内存可以减少磁盘I/O，因为更多的数据可以缓存在内存中。为PostgreSQL分配足够的内存（如shared_buffers和effective_cache_size）可以提高性能。3. CPU使用多核处理器可以提高并行处理能力，加速复杂查询的执行。确保服务器具有足够的CPU资源以支持预期的负载。4. 网络优化网络连接可以减少网络延迟和带宽限制对数据库性能的影响。使用高速、低延迟的网络连接和合适的网络配置可以提高性能。五、查询优化和索引设计1. EXPLAIN分析使用PostgreSQL的EXPLAIN命令分析查询执行计划，找出可能的性能瓶颈，如全表扫描、缺少索引或不合适的连接顺序等。2. 索引优化为经常用于过滤和排序的列创建索引可以提高查询性能。同时，避免过度索引以减少写操作的开销。使用复合索引和覆盖索引可以进一步提高性能。3. SQL重写和查询设计优化通过更改查询结构或使用不同的SQL函数来优化查询性能。例如，使用JOIN替代子查询、使用窗口函数替代复杂聚合等。此外，确保应用程序合理使用数据库连接和缓存以减少不必要的数据库负载。六、数据库参数调整与优化1. 共享缓冲区（shared_buffers）和有效缓存（effective_cache_size）调整根据系统内存大小和负载特性调整shared_buffers和effective_cache_size参数，以平衡内存使用和磁盘I/O。通常建议将shared_buffers设置为系统总RAM的10%-25%。将effective_cache_size设置为shared_buffers加上操作系统的文件缓存大小。在专用数据库服务器上，这通常可以设置为系统总RAM的50%-70%。具体数值应根据实际环境和负载进行调整。2. 维护工作内存（maintenance_work_mem）调整与优化增加maintenance_work_mem参数的值可以提高维护任务（如VACUUM和ANALYZE）的性能，但也会增加内存消耗。通常建议将其设置为几百MB作为起点，并根据实际需要进行调整。此外，可以考虑在非高峰时段执行维护任务以减少对性能的影响。3. 检查点（checkpoint）与日志设置调整与优化策略制定通过调整checkpoint_segments和checkpoint_timeout参数，可以平衡检查点的频率和性能影响。增加checkpoint_segments的值可以减少检查点的频率，但也会增加在崩溃时可能丢失的数据量。通常建议将其设置为32-64作为合理范围。此外，合理配置日志文件的大小和数量以避免日志写入成为性能瓶颈也是非常重要的。根据实际需求和数据量大小来制定合适的日志设置策略。

PostgreSQL数据库性能调优全攻略介绍本文旨在为PostgreSQL（简称PG）数据库的性能调优提供一个全面的指南。我们将覆盖多个方面，包括硬件和系统配置、查询优化、索引、以及数据库参数调整等。一、硬件和系统配置1. 存储系统存储系统是数据库性能的关键部分。推荐使用SSD，因为它们提供了比传统硬盘更高的IOPS和更低的延迟。如果可能，使用RAID 10配置，以在性能和冗余之间取得平衡。2. 内存增加系统的RAM可以减少磁盘I/O，因为更多的数据可以在内存中缓存。此外，为PostgreSQL分配足够的内存也是很重要的。3. CPU强大的CPU可以更快地处理查询。多核处理器对于并行处理尤其有益。4. 网络网络带宽和延迟可能会影响数据库性能，特别是在分布式环境或云环境中。使用高速、低延迟的网络连接是很重要的。二、查询优化1.EXPLAIN分析使用PostgreSQL的EXPLAIN命令来分析查询是如何执行的。这可以帮助你识别查询中的瓶颈，例如全表扫描或缺少索引。2. 索引优化确保经常用于查询过滤和排序的列上有索引。但是，不要过度索引，因为这会增加写操作的开销。3. SQL重写有时，通过更改查询结构或使用不同的SQL函数，可以显著提高性能。例如，使用连接（JOIN）代替子查询，或者使用窗口函数代替复杂的聚合。三、数据库参数调优1. 共享缓冲区（shared_buffers）shared_buffers参数控制PostgreSQL用于缓存数据的内存量。增加此参数的值可以减少磁盘I/O，但也会增加内存消耗。通常，将其设置为系统总RAM的10%-25%是一个合理的起点。2. 有效缓存（effective_cache_size）effective_cache_size参数是PostgreSQL用于估计可用缓存空间的参数。它应该设置为shared_buffers加上操作系统的文件缓存大小。在一个专用的数据库服务器上，这通常可以设置为系统总RAM的50%-70%。3. 维护工作内存（maintenance_work_mem）maintenance_work_mem参数控制维护任务（如VACUUM和ANALYZE）可以使用的内存量。增加此参数的值可以提高这些任务的性能，但也会增加内存消耗。通常，将其设置为几百MB是一个合理的起点。4. 检查点（checkpoint）检查点是PostgreSQL将缓存的数据写入磁盘的时间点。通过调整checkpoint_segments和checkpoint_timeout参数，可以平衡检查点的频率和性能影响。增加checkpoint_segments的值可以减少检查点的频率，但也会增加在崩溃时可能丢失的数据量。通常，将其设置为32-64是一个合理的范围。四、其他优化策略1. 分区表对于非常大的表，可以使用分区来改善性能。通过将数据分成较小的、更易于管理的部分，可以提高查询性能并减少维护工作量。2. 连接池使用连接池可以减少建立新连接的开销，并提高并发性能。流行的连接池解决方案包括PgBouncer和PgPool-II。3. 自动化优化工具可以考虑使用自动化优化工具，如pg_tune或AutoTune，来自动调整数据库参数。这些工具可以根据硬件和工作负载特性来推荐最佳设置。总结与建议性能调优是一个持续的过程，需要定期监视和分析系统性能以确定是否需要进行调整。使用工具如New Relic, DataDog或pgBadger可以帮助你更好地理解和可视化你的数据库性能。* 不要忘记备份你的数据和配置在尝试任何重大的性能调优之前。这可以确保在出现问题时你可以恢复到之前的状态。* 考虑使用扩展和第三方工具来增强PostgreSQL的功能和性能。例如，使用PostGIS扩展可以为地理空间数据提供强大的支持，而使用Citus扩展可以实现分布式数据库功能。* 最后，记住最好的优化策略通常是避免不必要的数据库操作和提高应用程序的效率。例如，通过缓存常用查询结果或减少冗余查询，可以大大减少数据库负载并提高应用程序的性能。

在PostgreSQL中，对于VACUUM或ANALYZE操作，只会对主表起作用，如果需要对分区表进行分析，需要分别对每个分区表进行操作。请问GaussDB的行为是否与之一致？

      测试环境：centos7.6和openEuler20.03扫描依赖包当我们不知道java项目是否包含native依赖的时候，可以使用工具扫描整个war或者jar包。鲲鹏代码迁移工具：cid:link_0以下是扫描结果：分析扫描结果sigar-lib-1.6.4.jar包调用了native的动态库libsigar-x86-linux.so，且该动态库未在已有的白名单里，故不能通过工具直接下载，需要手动编译。编译libsigar-aarch64-linux.so安装依赖yum install -y wget gcc gcc-c++ make cmake libtool autoconf automake ant unzip java-1.8.0-openjdk java-1.8.0-openjdk-devel maven 下载源码并解压               #下载          wget https://github.com/hyperic/sigar/archive/refs/tags/sigar-1.6.4.tar.gz         #解压         tar zxvf sigar-1.6.4.tar.gz      3.编译         #进入工程目录       cd sigar-sigar-1.6.4/bindings/java/        #修改ArchNameTask.java 79行-m64为-mabi=lp64       vi ./hyperic_jni/src/org/hyperic/jni/ArchNameTask.java ​#在openEuler操作系统中，需在linux_sigar.c文件中引入头文件sys/sysmacros.h cd ../../src/os/linux/linux_sigar.c ​​​编译sigar-lib-1.6.4.jar#下载 wget https://github.com/gridkit/sigar-lib/archive/sigar-lib-1.6.4.tar.gz #解压 tar zxvf sigar-lib-1.6.4.tar.gz #进入工程目录 cd sigar-lib-sigar-lib-1.6.4/ #拷贝libsigar-aarch64-linux.so cp /root/dev/sigar-sigar-1.6.4/bindings/java/sigar-bin/lib/libsigar-aarch64-linux.so  . #编译 mvn package ​FAQ（1）[cc] gcc: 错误：unrecognized command line option ‘-m64’问题截图：​问题描述：鲲鹏平台不支持-m64编译选项解决思路：将鲲鹏平台对应的编译选项设置为-mabi=lp64（2）/root/dev/sigar-sigar-1.6.4/src/os/linux/linux_sigar.c:1148:22: 错误：called object ‘major’ is not a function or function pointer问题截图：​问题描述：进入sigar-sigar-1.6.4/src/os/linux/linux_sigar.c，查看1148和1149行代码,major和minor函数未找到，可能缺少头文件。1148 #define ST_MAJOR(sb) major((sb).st_rdev) 1149 #define ST_MINOR(sb) minor((sb).st_rdev) 解决思路：在系统头文件路径下搜索关键字major和minor，查看头文件名。grep -r "major(" /usr/include/ grep -r "minor(" /usr/include/ ​将文件sigar-sigar-1.6.4/src/os/linux/linux_sigar.c中，引入头文件sys/sysmacros.h​

一般来说，影响数据库最大的性能问题有两个，一个是对数据库的读写操作，一个是数据库中的数据太大导致操作慢，对于前者我们可以适当借助缓存来减少一部分读操作，而针对一些复杂的报表分析和搜索可以交给hadoop和elasticsearch,对于写并发大，读也并发大，我们可以考虑分库分表，主从读写分离或者两者结合等方式来提高并发性和时效性，例如PG大并发写，大数据查看可以用elasticsearch与PG数据同步来读，可以启到很好的效果。ElasticSearch做为搜索服务器，在性能上确实优势突出，是当前流行的企业级搜索引擎。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web接口。主要用于实时搜索和分析引擎,，支持对结构化数据和非结构数据处理检索。例如，我们使用的数据库时Postgres数据库，主从配置，从库主要用于数据分析检索为主，如果使用postgres进行多表多维度全量方式检索分析用户行为等挖掘有价值的数据，这样性能上无法及时满足客户时时性要求，因此我们可以使用Elasticsearch数据库代替PG从库做为挖掘分析数据库，使用过程中发现两者表与数据的兼容性都还不错，而且展现数据的性能确实快，如下图是同一张表数据在postgres数据库中对应的表，在Elasticsearch数据库中对应，说明数据是兼容的。而在postgres数据库中针对visit_plan_qz 表3073920笔数据进行全量查询，耗时大于5分钟都无法正常展现出来，如果使用Elasticsearch进程全量查询仅使用0.0005秒就可以展现出数据，当然Elasticsearch会自动对该表划分为5个分片来展现数据。工作原理:PG关系数据库 ⇒ 数据库 ⇒ 表 ⇒ 行 ⇒ 列(Columns)Elasticsearch ⇒ 索引(Index) ⇒ 类型(type) ⇒ 文档(Docments) ⇒ 字段(Fields)可以看出Elasticsearch性能上的优势在索引，它提供强大的索引能力，Elasticsearch 是通过 Lucene 的倒排索引技术实现比关系型数据库更快的过滤Elasticsearch的索引思路:将磁盘里的东西尽量搬进内存，减少磁盘随机读取次数(同时也利用磁盘顺序读特性)，结合各种算法，用及其苛刻的态度使用内存。原文链接：cid:link_1zixun/2139.html

1.GaussDB集中式和分布式在SQL方面具体有多少差异，官方有没有整理相关性文档2.如有文档，在哪里可以查阅学习。3. GaussDB集中式和Oracle在SQL方面具体有多少差异，官方有没有整理相关性文档？如有文档，在哪里查阅学习？

华为鲲鹏云安装postgres 如何安装 postgis 和 pgrouting 这两个插件，去哪里获取支持aarch64架构的插件，是否有参考文档。