test 04 使用对应的pattern ops走索引在zh_CN也是列时也走索引
最近有人在IRC，Slack和Reddit上讨论使用int4/integer替代int8/bigint能够少4个字节。事实并非如此，来解释下。
基于规则的优化器，就是优化器在优化查询计划的时候，是根据预先设置好的规则进行的，这些规则无法灵活改变。举个例子，索引优先于扫描，这是一个规则，优化器在遇到所有可以利用索引的地方，都不会选择扫描。这在多数情况下是正确的，但也不完全如此：
在gpssh-exkeys -h localhost 这一步，显示无法连接本地 ssh。
环境介绍： 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在我试用的时
openGauss分区表支持两种索引：全局（global）索引和本地（local）索引。
这里的位图是什么参考这一篇：《Postgresql源码（52）bitmapset分析RelationGetIndexAttrBitmap》
版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/wzy0623/article/details/89051688
很早的一篇文字, 今天遇到了问题,开发问我怎么解决, 又翻出来, PG 的优越性比 ORACLE SQL SERVER MYSQL 高明的地方,就体现在下方的文字
不同的架构决定了产品不一样的特性，看完了PostgreSQL核心进程会发现并没有喜闻乐见的UNDO模块，既然没有UNDO，那么我在事务修改了一条数据， 发现数据改错了，突然不想改了数据还能回退吗？
在开始新一周的文字前，先打个广告，最近被腾讯云邀请将文章同步到云社区，很感谢。本身写这个从开始到目前都没有特别的功利心，仅仅是share 一些东西，如果大家看着好可以私信我，加微信共同提高技术水平。（Sorry 个人的名字属于隐私，不便透露）
PostgreSQL从小白到专家，是从入门逐渐能力提升的一个系列教程，内容包括对PG基础的认知、包括安装使用、包括角色权限、包括维护管理、、等内容，希望对热爱PG、学习PG的同学们有帮助，欢迎持续关注CUUG PG技术大讲堂。
该模块提供了一组度量来评估模型预测的质量。除非另有说明，典型的函数将采用一组“预测”和“观察”值，并使用它们来计算所需的度量。所有功能都支持分组（混淆矩阵除外）。
对于某些用例，当前存储设计是次优的。我们相信可以通过在”heap”操作和存储之间添加一个抽象层来进行改进。当前，存储设计基于按行组织页的假设：heapam.h假设：每个tuple只有一个元组头和一个数据区域，即包括HeapTuple及tuple逻辑操作的代码，比如delete、update、加锁。类似，执行器代码表示TupleTableSlot抽象层的元组，该抽象层下面是HeapTuple。2015年2ndQuadrant致力于在PG中实施列式存储项目，以下是根据实施过程中吸取的经验得出的计划。
这里假设，你已经在 k8s 上部署好了基于 Citus 扩展的分布式 PostgreSQL 集群。
如果打开这个参数，PostgreSQL服务器将尝试确保更新被物理地写入到磁盘，做法是发出fsync()系统调用或者使用多种等价的方法（见wal_sync_method）。
测试场景的限制GIN索引查询速度是很快的， 在实际生产中，可能出现使用gin索引后，查询速度依然很高的情况，特点就是执行计划中Bitmap Heap Scan占用了大量时间，Bitmap Index Scan大部分标记的块都被过滤掉了。
该文介绍了如何在PostgreSQL中实现交叉表查询，包括定义表、定义列、创建索引、查询结果集合并以及应用函数处理结果集等步骤。同时介绍了如何使用PL/SQL和SQL进行交叉表查询，以及如何使用PostGIS进行空间数据查询和处理。
《Postgresql源码（30）Postgresql索引基础B-linked-tree》
写了600 多篇博客文章后，我以为我已经掌握了cluster命令的复杂性 ，但似乎我还没有，所以现在让我们开始吧。
执行器的工作包括：work、get result，之前work的内容已经介绍过了，这里分析下执行器如何拿到执行结果。
当我们说起金融时间序列的预测，大家可能第一个想到的是预测股票价格。 然而，Chollet 的《Deep Learning with Python》一书强调，人们不应该尝试使用时间序列预测方法去预测股票价格。 他解释道，在股市中过去的数据并不是估计未来的一个好的基础。
墨墨导读：本文介绍 PostgreSQL 中的BRIN索引。为什么引人注意专门单独讲述这个性能？因为这就是活脱脱的 Oracle Exadata 中的 Storage Index 和 Oracle Database 12.1.0.2 中的新功能 Zone Maps。
pg_roaringbitmap是一个基于roaringbitmap而实现的压缩位图存储数据插件，支持roaring bitmap的存取、集合操作，聚合等运算。
关系型数据库中数据类型是一个重要话题。PG提供很多不同类型，但并不是所有类型都相同。根据需要实现的目标，可能应用需要不同列类型。本文主要关注三种重要的数据类型：整型、浮点型、数字型。最近，我们看到了一些与这个话题相关的案例，我认为应该与公众分享这些知识，以确保读者避免最近在客户端应用程序中遇到的一些坑。
PgSQL的优化器为一个查询生成一个执行效率相对较高的物理执行计划树。执行效率的高低依赖于代价估算。比如估算查询返回的记录条数、记录宽度等，就可以计算出IO开销；也可以根据要执行的物理操作估算出CPU代价。那么估算依赖的信息来源哪呢？系统表pg_statistic（列级别统计信息）为代价估算提供了关键统计信息。Analyze操作或者vacuum进行了统计信息采集，并将对数据按列进行分析，得到每列的数据分布、最常见值、频率等信息，更新到pg_statistic表。当然还有表级别的统计信息，存储在系统表pg_class：relptuples表示表的总元组数，relpages表示总页面数，等。
背景 通常在数据库中最小粒度的锁是行锁，当一个事务正在更新某条记录时，另一个事务如果要更新同一条记录（或者申请这一条记录的锁），则必须等待锁释放。 通常持锁的时间需要保持到事务结束，也就是说，如果一个长事务持有了某条记录的锁，其他会话要持有这条记录的锁，可能要等很久。 如果某张表的全表或者大部分记录要被更新的话，有几种做法。 1. 在一个事务中更新需要更新的记录，很显然时间可能很长，因为没有了并发。 2. 在多个事务中更新不同的记录，使用高并发来缩短更新的时间，但是就需要解决并发更新时存在的行锁冲突的问题。
导读：本文介绍 PostgreSQL 中的BRIN索引。为什么引人注意专门单独讲述这个性能？因为这就是活脱脱的 Oracle Exadata 中的 Storage Index 和 Oracle Database 12.1.0.2 中的新功能 Zone Maps。
那么首先我们的提出为什么我们需要一个扩展统计信息的方式来进行相关的工作，需求在哪里。一般情况下的查询是不需要这样的扩展，而有一些大表，特殊的查询的确有一个更有效的数据收集对于数据查询是更有利的。
在传统的数据库中，DBA最恨 听到的词就是，我要使用 BLOB 字段，或者类似的类型来处理，huge的数据，他可能是一段图形的在转换后的“乱码”，也可能是某个蹩脚 程序设计出来的 “怪胎”。如果是强有力的 DBER 可能直接驳回此类需求，但换来的是，“这不有这个字段嘛”， 为啥不让用，就你事多的，我就存几行诸如此类的，“欢迎词”。
最近有人问了关于POSTGRESQL 数据压缩的问题，其中有一个问题是关于修改了参数后，无法应用，并且数据库无法启动的问题，我们先从这里说起新的压缩模式。
PostgreSQL Basic PG中的MVCC(多版本并发)设计目的是读不阻塞写。PG中的所有的insert和update操作都是创建新的一行数据；update和delete都不是立即删除旧版本无用的数据。tuple是否可见是由snapshot决定。 PG中追踪每个表的Block可见性是通过表的vm文件。Table或者Index的可用空间管理是通过表或者索引的fsm文件管理，它是一个2级的binary tree，最底层存储了每个page可用空间，最上层聚合最低层的信息。 📷 📷 📷 PG目前支持多种
预设场景 假设系统中有两张大表在不停的写入数据，现在的需求是把两张大表做一个逻辑备份，要求两张表的数据必须一致。
最近发布了PG15 beta 2。本文关注对有NULL值的列进行UNIQUE约束的改进。虽然唯一约束的细小差别不如加速排序那样惊艳，但对于提高数据库开发人员对数据质量的控制来说，总归是一个好处。
知道我的人都了解，自 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，还有谁？
update t8 set info='87b5696b76a041a41495da0000000000' where id = 149370;
pglogical 是 PostgreSQL 的拓展模块, 为 PostgreSQL 数据库提供了逻辑流复制发布和订阅的功能。 pglogical 重用了 BDR 项目中的一部分相关技术。pglogical 是一个完全作为PostgreSQL 扩展实现的逻辑复制系统。完全集成，它不需要触发器或外部程序。这种物理复制的替代方法是使用发布/订阅模型复制数据以进行选择性复制的一种高效方法。支持 PG10、9.6、9.5、9.4 ，提供比 Slony、Bucardo 或 Londiste 更快的复制速度，以及跨版本升级。 我们使用的下列术语来描述节点和数据流之间的关系，重用了一些早期的 Slony 技术中的术语:
今天午休期间刷微信，看到云和恩墨的盖总转了一条朋友圈，说杨长老在Oracle中用SQL解海盗分金问题（原文《无往不利：用SQL解海盗分金的利益最大化问题》，看完之后手痒，决定试试在 PostgreSQL 中解决该问题。
[每周 Postgres 世界动态] 本文全网唯一源地址 产品新闻 信息来源：网址基础上整理。 pgsodium 新版本发布2.0.1. pgsodium 是一个用于 PostgreSQL 的加密库扩展，使用 libsodium 库用于高级加密算法。 pgBadger 新版本发布v11.7. pgBadger 是一个 PostgreSQL 性能分析器，用来基于日志构建快速、全面的报告。 博客动态 信息来源：网址 Timescale - 如何用 generate_series() 和 SQL 模拟测试数据 C
本文介绍了推荐系统中的矩阵分解方法及其在音乐推荐中的应用。通过对比不同的数据类型和分解方法，实验结果表明，基于低秩矩阵分解的推荐算法在音乐推荐中具有较好的效果。同时，本文还探讨了如何使用隐语义模型进行音乐推荐，并分析了推荐系统的实时性和扩展性问题，为推荐系统的研究和应用提供了有益的参考。
间隔删除数据，使用ctid(页面号，lp号)作为条件，发现数据并没有真正的从页面中删除
在HANA开发中，经常会遇到一些业务数据不连续，但是在最终输出的时候要求连续展示，尽管对应的业务数据为空。这时生成序列数据是非常重要的一步。HANA提供了多种用于生成不同类型序列的函数，以下是一些常用的序列生成函数以及它们的详细用法。
PostgreSQL 12的可拔插存储引擎--表访问方法以及bloackholes案例
最近在PG14中发现新增一个配置参数enable_memoize，通过此参数可以提升嵌套循环连接的性能，有人测试性能竟然能提升1000倍！
加字段慢的一个原因是数据‘搬迁’慢，另外一个重要因素是锁粒度特别大，容易产生阻塞。
报错是备库事务或者单SQL查询时间长，和备库的日志apply发生冲突，如果业务上有长事务、长查询，主库上又再修改同一行数据，很容易造成备库的wal日志无法apply。
关系型数据库都需要产生一个最佳的执行计划从而在查询时耗费的时间和资源最少。通常情况下，所有的数据库都会产生一个以树形式的执行计划：计划树的叶子节点被称为表扫描节点。查询节点对应于从基表获取数据。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
即时通信 IM
ICP备案
对象存储
实时音视频
