在一些应用程序中，可能需要对表的所有字段进行检索，有些字段可能需要精准查询，有些字段可能需要模糊查询或全文检索。 比如一些前端页面下拉框的勾选和选择。

　　这种需求对于应用开发人员来说，会很蛋疼，因为写SQL很麻烦，而当全表所有字段的模糊查询，应该如何做呢 ?关键技术还是pg_trgm

　　早上送给大家的新年大礼包，一年一个大版本是PostgreSQL社区的传统，虽然发布时间通常为秋天，还有一段时间，但是已经迫不及待地想看看2017金秋将要发布的10.0版本已经装备了哪些核武器。

　　模糊查询，是一个需求量很大，同时也是一个对数据库来说非常难缠的需求。对于前模糊(like '%xxx')，可以使用倒排B-TREE索引解决，对于后模糊(like 'xxx%')，可以使用B-TREE索引解决。 　　但是对于前后模糊(like '%xxxx%')，对于以及前后模糊的正则表达式，则很多数据库无从下手，无法优化，只能全表扫描，对每条记录进行单独的处理。PostgreSQL数据库的开放性使得这一切成为了可能，在数据库中进行前后模糊，正则表达查询的索引检索成为可能。

　　西游记中有一集“真假美猴王”，假的美猴王简直是克隆的，和孙悟空一模一样。一开始菩提祖师、如来佛祖、观音菩萨、就连最亲近的师父、师兄弟都分辨不出来，最后师父使出紧箍咒的绝招才辨别出来。

　　再往广泛的场景去想，还有更多的真假美猴王，比如套牌车(克隆车)，克隆人，ip伪装，MAC伪装。有什么技术手段可以真正的解决真假美猴王的问题呢？

　　为了使用让Postgresql运行起来性能更好，使用一些更高级的功能特性，我们经常需要升级版本。

　　PostgreSQL小版本可以实现平滑升级，但大版本升级就比较折腾，本文分享一些Postgresql大版本升级方法。

　　快过年了，提防人贩子，小孩要带好。很多家庭耗尽时间和金钱，找了很多年还是没有找到，最终选择了放弃。 社会中依旧还有很多爸爸妈妈还没有找到丢失的孩子，除了严打罪犯；作为IT人，我们能做什么吗 ？

　　为什么人贩子猖獗？如何才能让人贩子无处遁形？

　　Pipelinedb是基于PostgreSQL的一个流式计算数据库，纯C代码，效率极高(32c机器,单机日处理流水达到了250.56亿条)。同时它具备了PostgreSQL强大的功能基础，正在掀起一场流计算数据库制霸的腥风血雨。

　　在物联网(IoT)有非常广泛的应用场景，越来越多的用户开始从其他的流计算平台迁移到PipelineDB。

　　Postgresql官方终于要出分区了，开发线上已经看到提交分区代码了，下一个版本10带有分区功能应该没问题了，那么这个分区功能如何呢？且和我深入源码一探究竟。

　　PostgreSQL作为世界上功能最强大的开源数据库，窗口函数作为业务过程中进行数据统计必不可少的功能，对PG自然是不在话下，PG内置了大量的窗口函数。

　　本文就是和大家一起在实际业务场景下如何使用窗口函数进行一探究竟。。。

　　PostgreSQL 和它的LOGO大象一样，给人非常强大的安全感。就拿它的Feature来说，一个大的feature要打磨很多年才能正式的合并到master分支。
　　比如并行计算的特性，从9.4就开始准备，加入了work process和dynamic shared memory的功能，奠定了多进程并行执行的基础。 一直到9.6，经历了3年的开发，大量的测试，终于RELEASE了。

　　今天要说一说它的分区表，经历了几年的酝酿，终于在10.0加入到master了。

　　恢复数据是 dba 工作的一部分，特别是 pg 在做大版本升级时需要停机进行，所以希望 恢复数据的时间越短越好。那如何提高数据恢复的性能呢，下面说说那些参数有影响。

　　恢复数据的过程其实就是 io 的负载,特别考验硬盘的写能力，还有就是数据写入磁盘的 方法，另外一个就是 cpu 的处理能力，再一个就是内存的大量使用。。。

　　人类是群居动物，随着人口的增长，联络方式越来越无界化，人与人，人与事件，人与时间之间形成了一张巨大的关系网络。 有许多场景就是基于这张巨大的关系网络的。比如，猎头挖人、公安破案、金融风控。 　　本文将给大家揭示PostgreSQL是如何玩转金融风控，刑侦，社会关系，人脉关系需求的。

　　马上春节了，又到了火车票的销售旺季，一票难求的问题依旧存在吗？ 还记得10年前春节前买火车票得在放票前1天搬个小板凳去排队，对于热门路线，排一个晚上都有可能买不到票。

　　随着互联网的发展，几年前建设了12306网上购票系统，可以从电脑上买票，但是不要以为在电脑上就能买到票。 为什么呢？

PostgreSQL中的锁

　　在IoT的场景中，数据有流式分析的需求，也有存储历史数据的需求，同时还有数据挖掘的需求，搜索引擎可能也需要同一份数据，还有一些业务可能也要用到同一份数据。

　　但是如果把数据统统放到一个地方，这么多的业务，它们有的要求实时处理，有的要求批量处理，有的可能需要实时的更新数据，有的可能要对大数据进行分析。那么如何才能够更好的分享数据，保证数据的一致性，提高分享的实时性呢？

　　在英语中，名词通常都有复数，表示多个；形容词，过去式，动词等。 有large, larger, largest, stories, eating, did, doing, hacked这样的。

这可能会给分词带来一定的困扰，我们来看看PG默认的ts config怎么处理它的。

活动时间: 2017年1月7日（周六下午）
活动地点：江苏南京市江宁区国电南瑞实验中心·江宁区诚信大道19号主办方
活动内容: 本期围绕Oracle、MySQL、PostgreSQL进行技术分享，本期有来自沃趣科技、国电南瑞、阿里云、五星电器的技术大咖，与专家互动的同学将有机会获得数据库技术书籍礼品。

　　人生就像一场戏，有高潮，有尿点，有低谷。如果用曲线来描述漫漫人生路的话，怎么找出高潮、尿点、低谷呢？ 其实类似的场景还有很多，比如来自传感器的监控数据；服务器的监控数据；温度，湿度的变化数据；等等，都可以数字化，用曲线来表示。

　　找高潮、尿点、低谷有什么好的方法吗？导数、微积分、斜率、曲率、面积？当然，还是有方法的，也是PostgreSQL，它支持窗口，帧的查询。

　　刚刚过去的周末，PGConf.Asia 2016在日本东京举行，ＰＧ中文社区主席萧少聪参与了本次大会并进行了一个Keynote的演讲，并就此为大家带来大会最新的报道！

　　本次大会由日本两大PG组织 PostgreSQL日本用户会 及 PostgreSQL企业联盟 联合举办，大会为期2天在“死宅圣地” - 秋中原举行。

　　有一个这样的场景，一张小表A，里面存储了一些ID，大约几百个。另外有一张日志表B，每条记录中的ID是来自前面那张小表的，但不是每个ID都出现在这张日志表中，比如说一天可能只有几十个ID会出现在这个日志表的当天的数据中。

　　那么我怎么快速的找出今天没有出现的ID呢？这个QUERY会很慢，有什么优化方法呢。