半个PostgreSQL DBA,热衷于数据库及分布式技术。 - https://github.com/ChenHuajun - https://pan.baidu.com/s/1eRQsdAa
为了达到最大网络吞吐,socket send buffer size(SO_SNDBUF)不应该小于带宽和延迟的乘积。 之前我遇到2个性能问题,都和SO_SNDBUF设置得太小有关。 但是,写程序的时候可能并不知道把SO_SNDBUF设多大合适,而且SO_SNDBUF也不宜设得太大,浪费内存啊。
关于CAP理论,自从听说这个理论起,就觉得挺玄乎的。果然国外关于CAP的争论不休,唯有国内视乎将其视为圣经一样推崇,听不到半点质疑。 详细请看下面。 http://blog.csdn.net/chen77716/article/details/30635543我不是要否定CAP,实在没那个功力。
在执行SQL的时候,有可能需要限制SQL的最长执行时间。这个限制在JDBC和.NET Data Provider中分别通过下面两个方法设置。 其他数据库驱动可能也有类似的参数。 Statement.setQueryTimeout() DbCommand.CommandTimeout() 这个功能是很简单的,但是如何实现这个超时呢?不同的数据库驱动,可能会采取不同的方法。
SQL Server中有个rowversion,利用它可以实现乐观锁策略的并发更新。那么在PostgreSQL中有没有类似的东西呢? PostgreSQL中,最接近rowversion的就是系统隐藏列xmin。
PostgreSQL中的数据类型,以及与之相关的操作符和索引都是可以自由扩展的,因此可支持不同领域应用的定制。而且PG的扩展非常自由,自定义的数据类型,操作符以及索引类型和原生的具有相同的能力。
偶然从网友的这篇博客中发现pgbench的TPC-B测试结果中有一个比较奇怪的地方 http://blog.chinaunix.net/uid-20802110-id-4889543.
4.其它数据类型的GiST索引 GiST索引可适用于多维数据类型和集合数据类型,对多维数据类型使用Rtree的索引算法,对集合数据类型RD-tree或者签名文件(是不是也可以叫利用签名向量压缩的RD-tree)的索引算法。
3. hstore的GiST索引 hstore的GiST索引实现和全文检索的tsvector的GiST索引的实现差不过,都是签名文件索引。 3.
2. 全文检索的GiST索引实现 PostgreSQL的全文检索有GiST和GIN两种索引方式,应该选择哪种索引类型有时让人困惑。 还好,PG手册中有一段指导很有帮助。 http://58.58.27.50:8079/doc/html/9.3.1_zh/ ------------------------------------------------------------ 在选择要使用的索引类型时,GiST或者GIN考虑这些性能上的差异:GIN索引查找比GiST快约三倍GIN索引建立比GIST需要大约三倍的时间。
GiST索引是PostgreSQL中很神奇的一个东西,通过它有时可以轻松玩转多维数据。但是,在不恰当的使用场景下,它的性能表现也可能令人困惑。 1.概述 1.1 GiST为何物 GiST 的意思是通用的搜索树(Generalized Search Tree)。
PostgreSQL提供了几个事务快照函数,实测发现,通过这些函数取到的事务快照可能要比自己预想的要有一个延迟。 1. 功能说明 几个事务快照函数的功能说明参考PostgreSQL手册。
PostgreSQL的表里有几个系统隐藏列,xmax是其中一个,某些场景下我们可以利用PostgreSQL的xmax实现无锁的并发更新。本文介绍的消息或者任务队列的应用场景就是一例。
一般我们谈SQL执行时间都有意无意地把它认为是服务端执行SQL的时间。但是,有时候我们更关心从客户端看到的SQL执行总时间。比如客户在和其它数据库做性能对比的时候。 那么这个SQL执行总时间是如何构成的呢?这要分两种情况说明。
pg_trgm是用来做相似度匹配的,在一些情况下也可以拿来代替全文检索做字符匹配。 从大量数据中通过字符串的匹配查找数据的关键是索引,对字符串的精确相等匹配,前缀匹配(like 'x%')和后缀匹配(like '%x')可以使用btree索引,对中缀匹配(like '%x%')和正则表达式匹配就可以用pg_trgm的索引了。
PostgreSQL支持全文检索,其内置的缺省的分词解析器采用空格分词。因为中文的词语之间没有空格分割,所以这种方法并不适用于中文。要支持中文的全文检索需要额外的中文分词插件。网上查了下,可以给PG用的开源中文分词插件有两个:nlpbamboo和zhparser。
之前的一篇博客《PostgreSQL分区表的性能损耗验证》中,遇到100并发单行更新发生死锁(问题1)的问题。 这么简单的一条SQL,100个并发时居然会发生死锁,太不可思议了。发生死锁的SQLupdate_smallrange.
在CentOS 6.5 + PostgreSQL 9.3.4下运行一个高并发的pgbench测试,发现并发数超过一定数量(max_connections已经设成足够大了)的时候,执行会出错。
之前的一篇博客《PostgreSQL分区表的性能损耗验证》中,遇到1000分区的分区表更新和删除都执行失败(问题3)的问题。经过简单的调查发现原因竟然是OOM导致进程被杀。以下是相关错误消息 1.
在使用PostgreSQL的过程中,有时会遇到区域和字符编码相关的问题。我们就解决过几次这样的问题,因此感到这样的问题比较常见,所以去年我做了一个总结性的资料《PostgreSQL中的区域和编码》,并在PostgreSQL中国用户大会上进行了分享。
简单查询和扩展查询是PG前端和后端交互的时候,2种不同交互方法。简单查询时,前端发一个包含SQL的包过去,后端执行后返回结果。扩展查询则是把简单查询切分成Parse,Bind,Describe,Execute,Close等几个步骤,以达到执行计划复用的目的。
SQL的执行大致分为解析,优化和执行几个步骤。解析和优化的结果是执行计划,通常相同的SQL语句要被执行无数遍,并且每次执行很可能采用的是相同的执行计划。生成执行计划的过程是要花费时间的,特别是对一些复杂SQL。
最近在看PG query planner部分的代码 相对于mysql的代码, postgres代码的可读性很高大致画了下这部分的流程图, 辅助理解代码
1.背景 去年底的时候PostgreSQL中国社区组织了PostgreSQL 9.3手册的翻译工作,翻译中的html版的中文手册可以网站(http://58.58.25.191:8079/doc/html/9.3.1_zh/)在线浏览。
前段时间有同事咨询PostgreSQL相关的问题,发现他们用了一个自动生成的32字节的字符串作为唯一键,而这张表的数据量相当大,建议他们改用序列,可减少存储空间。但用序列有一点不一样,就是序列必须顺序产生,那么高并发访问时会不会成为性能瓶颈呢?下面做个测试验证一下。
C语言的打桩(Interpositioning)机制是一种用定制的函数替换链接库函数且不需重新编译的技术。甚至可用此技术替换系统调用(更确切地说,库函数包装系统调用)。说白了,编译时使用的动态库中的某个符号可能在运行时被可执行程序或另一个动态库的同名符号替换。
关于TIMESTAMP WITH TIME ZONE,SQL标准中有这么一段描述 SQL2008 TIMESTAMP and TIME may also be specified as being WITH TIME ZONE, in which case ever...
LC_CTYPE代表了区域中的字符分类,比如哪些字符是字母,哪些是数字,大小写等。PostgreSQL支持区域相关的行为,其底层实现是调用了操作系统提供的相关接口,比如判断字符大小写的isupper()。
PostgreSQL通过gettext实现对多语言消息的支持。消息的语言是英语还是中文可以通过postgresql.conf中的lc_messages控制。在启动PostgreSQL时,postmaster进程(你看到的进程名可能是postgres)会根据postgresql.conf中的lc_messages值设置进程locale(调用setlocale()),然后再fork出一堆其它进程。
关于Linux下的locale,网上讲这个资料不少,本没必要多说什么。无奈手贱,权当做个笔记吧。以下操作环境为CentOS 6.5 1. 查看当前locale [chenhj@node1 ~]$ locale LANG=en_US.
根据PostgreSQL的手册,PostgreSQL中hash索引有很大的缺陷,不推荐使用。 http://58.58.27.50:8079/doc/html/9.3.1_zh/indexes-types.html -----------------------------------------------------------------------------Hash 索引操作目前没有记录 WAL 日志,因此如果数据库崩溃有未写入的改变, 我们可能需要用REINDEX重建 Hash 索引。
使用ODBC访问PostgreSQL的时候,客户端和数据库的字符编码很可能会不一致,这时就需要进行字符编码转码。大多数场合,ODBC驱动(psqlODBC)和PostgreSQL后台可以很好地处理字符编码转码,不需要用户操心。
今天用Visual Studio 2010编译一个C工程时突然遇到下面这个编译错误。 fatal error LINK1123:failure during conversion to COFF:file invalid or corrupt 试了很多方法都没有用,包括微软官方的说明 http://blog.
3 共通的监控工具 前面介绍的PostgreSQL监控工具都偏向于性能分析,没有告警功能。而且它们只是针对PostgreSQL的监视,有时需要监控整个业务相关的系统,这时候就要考虑通用的监控工具了。
2.3 pgwatch http://www.cybertec.at/postgresql_produkte/pgwatch-cybertec-enterprise-postgresql-monitor/主要特性: - 配置简单 - 大量的监控图表 - 快速系统检查...
监控postgreSQL的方法很多,本文做个简单的比较。 大的方面,监控方法可以分为以下几种 1 直接利用PG提供的性能统计数据 PG的很多性能数据可以通过查询pg_stat_或pg_statio_开头的系统表获取。
1. 引言 我们的系统一旦上线跑起来我们自然希望它一直相安无事,不要宕机,不要无响应,不要慢腾腾的。但是这不是打开机器电源然后放任不管就可以得到的(如果你就是这种情景,说明你人品太好了)。
Solaris的Patch策略,简单而言,可以概括为以下几点 1)Bugfix打Patch 2)功能强化发布Release更新 Release更新的名称如下: ... Solaris 10 9/10 (Update 9) Solaris 10 8/11 (Update 10) Solaris 10 1/13 (Update 11) 其中的1/13指13年1月。
Linux和Windows和换行符不一样。Windows下是CRLF(\r\n或0d0a),Linux下是LF(\n或0a)。在Linux下有时会遇到从Windows过来的文本文件,这些文件带了Windows换行符,Linux下进行脚本处理时有可能会出一些莫名其妙的错误。
前一篇>中为确保共享资源的不被破坏,配置了3节点集群,本文想验证一下双节点时有什么风险。 Pacemaker的手册上也有描述,Pacemaker支持法定投票和资源抢占2种方式防止脑裂。
1. 背景 因为工作的原因,需要考一个PostreSQL技术认证。经过一些准备,终于在今年的3月和5月参加并通过了EnterpriseDB的Associate和Professional认证。
1.概述 关于PostgreSQL的HA有很多种解决方案,各有利弊,具体可参考PostgreSQL官方手册。本文介绍共享存储HA的搭建方法。http://www.postgresql.org/docs/9.3/static/different-replication-solutions.html 2.总体设计 测试环境由3台VMWare虚拟机构成。
BufferedStream的作用是给另一流上的读写操作添加一个缓冲层,改进IO效率。但最近在使用Npgsql(内部使用BufferedStream包装了NetworkStream)的过程中,发现BufferedStream有2个严重的问题,或者可以说是Bug。
最近同事在测试PostgreSQL C库libpq的IPV6时,使用了fe80的本地链接地址fe80::250:56ff:fe8d:6927(本机地址),结果报下面的错误:Invalid argument 后来知道link-local地址需要指定网卡设备,于是在IPV6地址后面加上"%eth0"就可以了。
1. 委托1.1 概述 委托相当于C语言的函数指针,但与函数指针不同的是委托是强类型的,使用起来更安全也更方便。而且委托还支持多路广播和异步调用。看看下面这个最简单的委托的例子 Code: 点击(此处)折叠或打开 ...
以下针对CentOS6.5,配好repo源后,使用yum install可以很容易的安装软件。1. CentOSCentOS 6.5自带的repo或CentOS 6.5安装DVD(CentOS-6.5-x86_64-bin-DVD1.iso) 包含软件及版本: pacemaker-1.1.10-14 resource-agents-3.9.2 cluster-glue-1.0.5-6 corosync-1.4.1-17 注:resource-agents比较旧,如果搭建pgsql 9.x的流复制HA,还是要用需要最新的pgsql RA。
通过VMware克隆虚拟机后,新虚拟机往往不能正确识别网卡,就需要重新配置。 下面是centos下重新配置网络的例子。 1. 虚拟网卡的设置 我的虚拟机中装了Host-only和NAT 2个虚拟网卡。
一条SQL语句采用哪个执行计划是由优化器根据代价估算自动选择的,但如果希望使用指定的执行计划,就需要进行干预。Oracle中通过提示(hint)干预特点SQL的执行计划,PostgreSQL本身也可以通过enable_bitmapscan之类的参数进行调节,但这些参数是针对会话的,对优化器的控制没有提示来的直接,也没有提示那么精细。
C#中virtual,abstract,override用于方法重载,子类覆盖了父类的相同方法,父类中的实现不可能再被外面调用。 new的作用是投影(shadowing),子类隐藏了父类的相同方法,通过强制类型转换外面还可以调用父类的实现。
在延续了许久的2.0.x系列之后,Npgsql社区终于在今年3月发布了Npgsql 2.1.1。这个版本有很多重大改进,一会我会列出来。如果你细心观察代码,你会惊讶的发现几乎一半的代码被修改了。
1. pgjdbc的整体架构2. 协议流 PostgreSQL的客户端与服务端通过协议消息通信,下面以pgjdbc执行一个简单的SELECT为例说明前提 已定义以下的表。 create table tb1(id int,c1 text); insert into tb1 values(1,'abcd'); 执行的SELECT语句 对动态参数代入值1执行下面的SELECT语句 select * from tb1 where id = ?; SELECT执行的流程 注:)为了简单起见,每个消息的请求和响应画成了依次同步发生。