Oracle 的AWR 报告是很出名的，通过他可以获得数据库很多的信息，并对数据库的操作和调整有着指导的意义，而PG 如何在不花钱的情况下，完成这个工作，并且还要做的更好，更完美。谁说花钱的就更好？？？
故事的从PG的慢查询说起--
PostgreSQL 的慢查询，Slow Query , 今天在群里面看到一个小哥提交的POSTGRESQL 的语句，说是从昨天下午运行的语句，到今天上午还没有跑出来，我了一眼，我惊叹，这语句还能这样写，估计放到哪个数据库上都给你跑不出来，PG还算好，还和老牛一样在给你运行，碰上脾气不好的早给你扔在半路上了。
怎么能发现这些语句，并且帮助开发共同努力，提高自己帮助别人，达到双赢的这才是我们该做的。
首先的提及一个问题，PG如何来抓慢查询，这是突然想到MYSQL的慢查询的抓取，其实在这里，PG的慢查询的记录有点类似MYSQL，但又不完全一样。
1 记录你的慢查询
一般你想当场抓到那些慢语句，是很困难的，所以我们必须的有一个小本本，并且在你忙别的的时候，小本本疯狂的监控，那些本不该出现的东西。当然如果你太严格，你的人缘估计也好不到哪里去，所以适当的对某些还算可以的语句进行防水，也是你的工作之一，如何防水，指标是什么，一般认为，时间成本是第一重要的。语句可以写的烂，但如果慢那就不要怪 DBer们出手了。
PostgreSQL 的小本本如何来设置
ONE ， 打开你的log 记录过滤器，在postgresql.conf中找到
log_min_duration_statement = 慢查询容忍的时间 ， 这应该是你的第一需要做的。
当然你还可以调整你的日志的记录的一些格式的问题，具体请见图
如果你要查看一些查询的等待的情况，你也需要打开下面图中的开关
同时下面关于log的参数也需要自己衡量一下进行打开，最好是要给你的日志一个目录
在调整好你的LOG 记录后，PG会如实的给你开始记录， 但马上应该有人会反应出，你这个有问题，你看看人家 MYSQL的记录，慢查询， 错误日志，是分开的，你这个都在一起看上去怎么那么的乱。
好了，现在就的祭出PG 的大招，PGBADGER，来让人们心服口服。先看PGBADGER自动生成的页面，不看过程看疗效。
目蛮多的，其实这个页面的生成根据个人调整的PG的记录的日志后，分析出来的，通过pgbadger 自动对日志扫描后，产生的页面。
如果动手能力强，可以做出一套定时，生产出数据库整体分析报告的动态页面，并还有历史记录可以进行查询，在某些功能上应该已近达到AWR 报告或超过AWR报告的程度，至于美观度，这是仁者见仁，不过看过ORACLE 的AWR，如果你说这个 丑，我也只能呵呵了。
下面可能是大家关心的慢查询的问题，PostgreSQL 的AWR (PGBADGER)
详细的展示了慢查询的信息，下图，（里面有一些超过我设定的3秒的语句，例如一次性插入 10000000 一千万的数据，耗费的时间在 1分52秒,如果是服务器应该还会更快，实验室在我的笔记本上进行的）
可以说在目前的四大数据库里面，这样的解决方案，真的是良心了。
当然除了这样可以定期自动生成的报告，同时我们还可以进行一个手动或二次开发的发现当前运行时间较长的语句。
通过图中的语句，（条件可以调整），动态的来查看我们当前的系统是否有正在进行的操作的语句较慢的情况。
当然文字写到这里，本来想就此打住，不过好东西的大家分享，postgresql中另外一个工具，pgcluu 可以进行整体数据库的分析，以及关键参数的分析并展示，下图为pgcluu 生成的页面，包含了整体instance 下所有数据库的信息，包含表，索引，缓冲，命中率等详细的信息，让你更快更强的了解你数据库的情况。
所以不要认为开源的东西就没有商业做的好，最近有些人和我说担心MYSQL 被甲骨文妖魔化，其实还好，你可以使用percona 的版本，或者MariaDB，当然还有PG，MONGODB ，至少在被别人扼住喉咙的时候，我们还能继续活下去。