rudy gao

--checkpoint各参数的值checkpoint_segments 最多的wal log数量，到达后会激发checkpoint，通常设定在30就好checkpoint_timeout 一般设置15-20分钟，常的可以设定1天也没关系checkpoint_completion_target 这个保持不动就好。内建是0.5，意思就是每个checkpoint预计在下个checkpoint完成

--原始表结构如下：postgres=# \d+ postgres_s1_log Table "public.postgres_s1_log" Column | Type | Modifiers | Storage | Stats

--今天在使用postgres_fdw做远端数据库转储时，发现本地所使用的字符集与远端是不同的，造成插入数据错误postgres=# insert into t select * from for_t;    ERROR:  character with byte sequence 0xe7 0xa6 0xb4 in encoding "UTF8" has no equivalent in

--今天查看pg_statsinfo报告时发现有如下警告,说明字段物理行序和逻辑行序相关不大correlation of the clustered table fell below threshold in snapshot '2015-11-30 08:30:00' --- 't.order_num', 44.01 % (threshold = 70 %)correlation

--PG并没有像Oracle那样的undo来存放旧版本；而是将旧版本直接存放于relation文件中。那么带来的问题就是dead tuple过多，导致relation文件不断增大而带来空间膨胀问题。--为了解决这个问题，PG中引入了vacuum后台进程，专门来清理这些dead tuple，并回缩空间--创建测试数据postgres=# create table t (id in

--查看数据库临时表空间位置--temp_tablespaces是表空间名称的列表，当列表中有一个以上名称时， PostgreSQL 每次临时对象被创建时选择一个列表中的随机数；--除了在一个事务中之外，先后创建临时对象放置在列表连续的表空间中。 --如果列表中选定的元素是一个空字符串， PostgreSQL 会自动使用当前数据库的缺省表空间 select * from pg_settin

--如果系统出现访问缓慢，首先可以通过zabbix查看系统中的数据库连接数，cpu使用率，内存使用率，swap使用率，以及系统io吞吐是不是有明显的抖动--如果数据库连接数突增，可能是系统访问量突然增大，更有可能是数据库执行一个或多个sql，造成资源争用，数据库处理速度跟不上向数据库发送请求的速度--如果cpu空增，内存变动不大，可能是数据库在进行大量的计算，比如sql的聚合操作--如

--mysql的profile可用于查看一个sql的具体消耗show profile all for query 1\G;--profiling has a default value of 0 (OFF)mysql> SELECT @@profiling;+-------------+| @@profiling |+-------------+| 0 |+-

--对于分区表constraint_exclusion 这个参数需要配置为partition或onpostgres=# show constraint_exclusion ; constraint_exclusion ---------------------- partition --创建父子表, 用于存储分区数据create table t(id int primary

技术的争论假如现在需要对user表的username字段和last_update_time字段建立组合索引，有如下两种方案方案A:index(username,last_update_time)方案B:index(last_update_time,username)到底哪种好呢？select something from users where user

以下内容转载自：PostgreSQL 9.5 new feature - BRIN (block range index) indexPostgreSQL 9.5引入的一个全新的索引访问方法BRIN（block range index），这个索引存储了表的连续数据块区间以及对应的数据取值范围。比如一张表有1000个数据块，我们建议一个BRIN在ID（假设这个表有ID字段）上的索引。

--由于pg中表和索引的信息收集都是基于时间点的，对于以往的信息无法与现在的信息进行对比，故写下此工具进行统计信息收集--创建数据信息的schemacreate schema db_stat;--创建收集信息的基础表create table db_stat.snapshot_pg_stat_all_indexes(relid int,indexrelid int,schemaname

PG默认每个page的大小为8K，PG数据页写入是以page为单位，但是在断电等情况下，操作系统往往不能保证单个page原子地写入磁盘，这样就极有可能导致部分数据块只写到4K(操作系统是一般以4K为单位)，这些“部分写”的页面包含新旧数据的混合。在崩溃后的恢复期间，xlog 里面存储的记录变化信息不够完整，无法完全恢复该页。PG为了解决这类问题，full_page_write机制孕育而生。什么

目录[-]pg_buffercachepgfincorepg_prewarmdstatLinux ftools使用pg_prewarm预加载关系/索引:pgfincore 输出: 怎样刷新在操作系统缓存中的关系/索引 ?使用pg_prewarm的range功能预加载随机块.缓存.... !!, 它很难在一篇文章中解释清楚。但是我会努力分享

pg_trgm是用来做相似度匹配的，在一些情况下也可以拿来代替全文检索做字符匹配。从大量数据中通过字符串的匹配查找数据的关键是索引，对字符串的精确相等匹配，前缀匹配(like 'x%')和后缀匹配(like '%x')可以使用btree索引,对中缀匹配(like '%x%')和正则表达式匹配就可以用pg_trgm的索引了。下面用一个例子说明一下。1.环境CentOS 6.5

--当update语句执行时，如果其可以获得锁其会首先获得一个排它锁 ExclusiveLock--在session 1 中 开启一个事务postgres=# begin;BEGINpostgres=# update t set user_name='test rudy' where id=1;--在session 2 中进行查询postgres=# SELECT locktype

--区域支持是在使用 initdb 创建一个数据库集群的时候自动初始化的，但可在创建数据库时单独指定--区域设置特别影响下面的 SQL 特性* 查询中使用 ORDER BY 或者对文本数据的标准比较操作符进行排序* upper, lower 和 initcap 函数* 模式匹配运算符(LIKE, SIMILAR TO, 以及 POSIX-风格的正则表达式)； 区域影响大

--安装yum包 yum -y install bzr libtool --对压缩包进行解--注意不要在mysql的官网下载，因为其只支持mysql不支持pghttps://github.com/akopytov/sysbench/tree/0.4tar zxf sysbench-0.4.12-1.1.tgz mv sysbench-0.4.12-1.1 sysbenchunz

PostgreSQL CLUSTER意在将表按照索引的顺序排布. 可以通过ctid来观察这个排布, 或者通过pg_stats.correlation来观察这个排布. 下面来举个例子 : 创建测试表 : digoal=> create table test (id int, val numeric);CREATE TABLE插入测试数据 : dig

--当pg开启一个事务，执行dml操作时，如果另一个事务要修改表结构，其不得不等待--session1 中执行dmlpostgres=# begin;BEGINpostgres=# select pg_backend_pid(); pg_backend_pid ----------------           4144(1 row)postgres=

注意PostgreSQL的unlogged table是不记录xlog的，所以在备库上没有unlogged table的数据记录。同时，数据库在进入恢复状态时，为了保证数据的一致性，postgresql会自动清除unlogged table的数据文件。那么问题来了，万一你不小心误创建了unlogged table，你可能一开始会没有感知，但是一旦发生以下情况，你会发现数据不见了。

在多核系统中，一般TPS会随并发数的增加而提升，但是当并发数超过一定的数值（如CPU核数的2到3倍以后），性能开始下降，并发数越高，下降越严重。例子：更新500万记录表中的1条随机记录。开8000个并发。create table test_8000 (id int primary key, cnt int default 0);insert into test_8000 s

postgresql的9.4版本出来有一段时间了，也更新了很多内容，其中之一是比较感兴趣的物化视图的更新，对比原先的物化视图语法，新增了一个CONCURRENTLY参数。  一、新语法：--创建语法,未有更新CREATE MATERIALIZED VIEW table_name [ (column_name [, ...] ) ] [ WITH ( storage_p

检查点，通俗的理解就是数据库处于数据一致性，完整性的点。因此在这个点之前提交的事务确保数据已经写入数据文件，事务状态已经写入pg_clog文件。通常创建检查点会需要一个漫长的过程，那么怎么保证数据的一致性和完整性呢？从数据恢复（XLOG）的角度来看，检查点在XLOG文件中分为两个位置，一个是逻辑位置，一个是物理位置。逻辑位置即开始位置，也是一致性位置，在这个位置之前

秒杀场景的典型瓶颈在于对同一条记录的多次更新请求，然后只有一个或者少量请求是成功的，其他请求是以失败或更新不到告终。例如，Iphone的1元秒杀，如果我只放出1台Iphone，我们把它看成一条记录，秒杀开始后，谁先抢到（更新这条记录的锁），谁就算秒杀成功。例如：使用一个标记位来表示这条记录是否已经被更新，或者记录更新的次数（几台Iphone）。update tbl se

-- 当我们需要排序字段时，比如order by name,如果name字段定义时没有not null时，就有可能涉及到null值的排序-- 如果不注意，可能会造成隐藏的bug，pg默认null是无穷大，在升序时排在最后面，当然在排序时也可以指定 nulls first 或 nulls last-- 具体使用方法在此不在复述，本文主要是讲的是在创建索引时指定 nulls first 或 nul