环境介绍: OS:Centos 6.4 64bit Database:PostgreSQL9.4 Memory:2G CPU:1核 下载安装: 在pgfoundry下载pgfincore-v1.1.1.tar.gz,,将源码解压到数据库源码下的contrib下。不要在其github上下载,目前应该有一些bug,最新版本为1.1.1,1.1.2在我试用的时
不同的架构决定了产品不一样的特性,看完了PostgreSQL核心进程会发现并没有喜闻乐见的UNDO模块,既然没有UNDO,那么我在事务修改了一条数据, 发现数据改错了,突然不想改了数据还能回退吗?
openGauss分区表支持两种索引:全局(global)索引和本地(local)索引。
《Postgresql源码(30)Postgresql索引基础B-linked-tree》
最近有人在IRC,Slack和Reddit上讨论使用int4/integer替代int8/bigint能够少4个字节。事实并非如此,来解释下。
test 04 使用对应的pattern ops走索引在zh_CN也是列时也走索引
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/wzy0623/article/details/89051688
预设场景 假设系统中有两张大表在不停的写入数据,现在的需求是把两张大表做一个逻辑备份,要求两张表的数据必须一致。
最近有人问了关于POSTGRESQL 数据压缩的问题,其中有一个问题是关于修改了参数后,无法应用,并且数据库无法启动的问题,我们先从这里说起新的压缩模式。
这里假设,你已经在 k8s 上部署好了基于 Citus 扩展的分布式 PostgreSQL 集群。
pg_rewind 相比 pg_basebackup 和 rsync 这样的工具来说,优势是它不需要从源目录拷贝所有的数据文件,而是会对比时间线发生偏离的点,只拷贝变化过的文件,这样对于数据量很大的情况下速度更快。
values lists用于构建常量表,常量表的数据只存在于SQL中,无需在磁盘上创建出来。
测试场景的限制GIN索引查询速度是很快的, 在实际生产中,可能出现使用gin索引后,查询速度依然很高的情况,特点就是执行计划中Bitmap Heap Scan占用了大量时间,Bitmap Index Scan大部分标记的块都被过滤掉了。
PostgreSQL从小白到专家,是从入门逐渐能力提升的一个系列教程,内容包括对PG基础的认知、包括安装使用、包括角色权限、包括维护管理、、等内容,希望对热爱PG、学习PG的同学们有帮助,欢迎持续关注CUUG PG技术大讲堂。
近期同事在讨论如何在PostgreSQL中一张大表,添加一个带有not null属性的,且具有缺省值的字段,并且要求在秒级完成。 因为此,有了以下的实验记录: 首先我们是在PostgreSQL 10下做的实验: postgres=# select version(); version ---------------
在gpssh-exkeys -h localhost 这一步,显示无法连接本地 ssh。
GlobalTransactionManager(简称 GTM), 是全局事务管理器,负责全局事务管理。GTM 上不存储业务数据。
如果大家熟悉PG的发布与订阅的话,那么对于本文理解应该很有帮助。接下来我们来看下分布式数据库TBase如何做多个实例或多个库之间的数据同步多活的。 在业务场景中我们经常可能会用到某一部分数据,但数据源头又是来自多个库的入库数据,比如我希望南区的A实例的某个库或表的数据能够汇集到北区B实例的某个库或者某个表中,只要A库中的数据的增删改的变化,能够即时的同步到B库,但B库的操作对不会影响A库。接下来我们就动手来看下TBase 的数据多活发布订阅。
背景 通常在数据库中最小粒度的锁是行锁,当一个事务正在更新某条记录时,另一个事务如果要更新同一条记录(或者申请这一条记录的锁),则必须等待锁释放。 通常持锁的时间需要保持到事务结束,也就是说,如果一个长事务持有了某条记录的锁,其他会话要持有这条记录的锁,可能要等很久。 如果某张表的全表或者大部分记录要被更新的话,有几种做法。 1. 在一个事务中更新需要更新的记录,很显然时间可能很长,因为没有了并发。 2. 在多个事务中更新不同的记录,使用高并发来缩短更新的时间,但是就需要解决并发更新时存在的行锁冲突的问题。
利用数据多活同步mc.public.test_repl到postgres.public.test_repl的数据。
在使用GaussDB(DWS)过程中经常会创建自定义函数,总结了多结果集返回的使用方法。
报错是备库事务或者单SQL查询时间长,和备库的日志apply发生冲突,如果业务上有长事务、长查询,主库上又再修改同一行数据,很容易造成备库的wal日志无法apply。
PostgreSQL中大量更新或者删除记录后,加上autovacuum参数未做优化或设置不当,会导致表及索引膨胀。生产环境除了手动使用vacuum之外,还有两个比较常用的工具:一个是pg_repack,另外一个是pg_squeeze。
PostgreSQL 10 版本开始支持逻辑复制,在12版本之前逻辑复制仅支持普通表,不支持分区表,如果需要对分区表进行逻辑复制,需单独对所有分区进行逻辑复制。
如果打开这个参数,PostgreSQL服务器将尝试确保更新被物理地写入到磁盘,做法是发出fsync()系统调用或者使用多种等价的方法(见wal_sync_method)。
PostgreSQL 12的可拔插存储引擎--表访问方法以及bloackholes案例
写了600 多篇博客文章后,我以为我已经掌握了cluster命令的复杂性 ,但似乎我还没有,所以现在让我们开始吧。
基于规则的优化器,就是优化器在优化查询计划的时候,是根据预先设置好的规则进行的,这些规则无法灵活改变。举个例子,索引优先于扫描,这是一个规则,优化器在遇到所有可以利用索引的地方,都不会选择扫描。这在多数情况下是正确的,但也不完全如此:
对于某些常进行archiver或者 purge操作的表而言,如果我们不定期回收表空间,则表体积会越涨越大。
间隔删除数据,使用ctid(页面号,lp号)作为条件,发现数据并没有真正的从页面中删除
最近发布了PG15 beta 2。本文关注对有NULL值的列进行UNIQUE约束的改进。虽然唯一约束的细小差别不如加速排序那样惊艳,但对于提高数据库开发人员对数据质量的控制来说,总归是一个好处。
前面一篇文章着重讲述了 B+ 树索引,实际上一些数据库中,树索引除了 B+ 树结构,还有其他的一些比较常见的索引结构。
pglogical 是 PostgreSQL 的拓展模块, 为 PostgreSQL 数据库提供了逻辑流复制发布和订阅的功能。 pglogical 重用了 BDR 项目中的一部分相关技术。pglogical 是一个完全作为PostgreSQL 扩展实现的逻辑复制系统。完全集成,它不需要触发器或外部程序。这种物理复制的替代方法是使用发布/订阅模型复制数据以进行选择性复制的一种高效方法。支持 PG10、9.6、9.5、9.4 ,提供比 Slony、Bucardo 或 Londiste 更快的复制速度,以及跨版本升级。 我们使用的下列术语来描述节点和数据流之间的关系,重用了一些早期的 Slony 技术中的术语:
PG 最近的使用中,发现这个数据库确确实实是一个无底洞,东西太多了,但学习一样东西都是通过主干和分支的方式来学习,后续的学习其实有的时候是靠自觉和运气。
PostgreSQL Basic PG中的MVCC(多版本并发)设计目的是读不阻塞写。PG中的所有的insert和update操作都是创建新的一行数据;update和delete都不是立即删除旧版本无用的数据。tuple是否可见是由snapshot决定。 PG中追踪每个表的Block可见性是通过表的vm文件。Table或者Index的可用空间管理是通过表或者索引的fsm文件管理,它是一个2级的binary tree,最底层存储了每个page可用空间,最上层聚合最低层的信息。 📷 📷 📷 PG目前支持多种
PG流复制场景下,默认配置下, 如果在PG从库执行长时间的查询,会出现查询的报错。提示
知道我的人都了解,自 2018 年比较正式地学习 Rust 以来(在此要感谢张汉东老师的大力推荐),我慢慢被 Rust 征服,成为一名不折不扣的拥趸。我的业余项目,90% 都是用 Rust 写就的,另外 10% 基本被 typescript(前端)和 python(主要是 notebook)瓜分。我对 Rust 热爱也体现在我的公众号和 B 站上,近两年发布的内容,主要和 Rust 有关。然而,我很少直接吹捧 Rust,更多是通过 “show me the code” 来展示 Rust 的美妙。这个周末,在 reddit/rust 版,我无意发现了 pgx 这样一个使用 Rust 来撰写 postgres extension 的集成工具,在深入地了解其文档并写了几百行代码后,我立刻就被那种直击心灵的简约之美冲破了防线,不得不在此吹上一波。如此优雅地解决另一个生态系统(postgres)的扩展的问题,我就想说,除了 Rust,还有谁?
这里的位图是什么参考这一篇:《Postgresql源码(52)bitmapset分析RelationGetIndexAttrBitmap》
执行器的工作包括:work、get result,之前work的内容已经介绍过了,这里分析下执行器如何拿到执行结果。
语义分析结果来看,insert语句都会构造插入表和数据表两张表(RangeTblEntry),数据表可能是值构造出来的,或者是select查询出来的。
关系型数据库都需要产生一个最佳的执行计划从而在查询时耗费的时间和资源最少。通常情况下,所有的数据库都会产生一个以树形式的执行计划:计划树的叶子节点被称为表扫描节点。查询节点对应于从基表获取数据。
PostgreSQL13.0于2020年9月24日正式release,13版本的PG带来很多优秀特性:比如索引的并行vacuum,增量排序,btree索引deduplication,异构分区表逻辑订阅等。在这里面最闪亮的特性非deduplication莫属。
参考:https://www.xmmup.com/zaidockerzhongkuaisutiyangreenplum-7-0-0.html
在传统的数据库中,DBA最恨 听到的词就是,我要使用 BLOB 字段,或者类似的类型来处理,huge的数据,他可能是一段图形的在转换后的“乱码”,也可能是某个蹩脚 程序设计出来的 “怪胎”。如果是强有力的 DBER 可能直接驳回此类需求,但换来的是,“这不有这个字段嘛”, 为啥不让用,就你事多的,我就存几行诸如此类的,“欢迎词”。
It's a long long story, 从 PG 8.3 引入了Heap-Only-Tuple, 主要的作用在用于减少更新所需的I/O数量,基于postgreql 的原理行的更新等于插入新的tuple,基于多版本控制MVCC, Postgres中的更新包括查找要更新的行,并将该行的新版本插入数据库,引入的问题就是显而易见的,索引,这就需要更多的I/O,数据要重新插入到表上的每个索引中。在插入的过程中需要先读取每个相关的索引,新版本行的物理位置与旧版本的物理位置不同。那一个表中有的索引越多,更改的数据量越大,牵扯的索引的消耗就越大。
领取专属 10元无门槛券
手把手带您无忧上云