一个表的数据量达到一定程度后，稳定性和性能就会出现瓶颈，"化整为零"对DBA 来说无疑是一个很好的选择，此时如何分表就成为摆在业务线开发同学和 DBA 面前的一道不可回避的课题。

相对于传统的开发同学自己根据业务及自己在应用代码中实现分表的方案，本文介绍一下 PostgreSQL 中如何实现对业务相对透明的分区方案。

PostgreSQL是一个功能非常强大的、源代码开放的客户/服务器关系型数据库管理系统（RDBMS），PostgreSQL被业界誉为“先进的开源数据库”，支持NoSQL数据类型（JSON/XML/hstore），主要面向企业复杂查询SQL的OLTP业务场景，提供PostGIS地理信息引擎、阿里云自研多维多模时空信息引擎等。

本文着重介绍PostgreSQL的数据目录，其中保存着配置文件、数据文件、事务日志和WAL日志等重要文件，所有客户创建的数据文件和初始配置文件都可以在数据目录中找到，因此数据目录是重要的客户价值所在。

Re-ordering table columns to avoid wasting space for data type alignment.

Braintree Payments uses PostgreSQL as its primary datastore. We rely heavily on the data safety and consistency guarantees a traditional relational database offers us, but these guarantees come with certain operational difficulties. To make things even more interesting, we allow zero scheduled functional downtime for our main payments processing services.

DBA 经常需要排查某一个事务中有哪些 SQL 的场景。典型的 case 就是 DB 有一个 lock 报警，从系统表中查看发现是1个 update 等待的 SQL 是1个 select。熟悉 PostgreSQL 的同学都知道：在 PostgreSQL 中，由于特有的 MVCC 机制，读不阻塞写，写不堵塞读。

那么为什么会产生这种 lock？

实际就是因为这个 select 处于一个事务中，事务中有其他 update/delete 等写入操作持有后面的其他事务中的 update 操作所需要的 lock。此时就需要到 DB log 去排查这个 select 所处的事务的完整的全部 SQL，反馈给业务线的开发同学，以便于进一步优化。

最近有业务线的同学向 DBA 提出这样的需求:“我的表里有很多敏感数据，怎么给使用者(从 DBA 角度来看就是 DB User)指定查看某些特定行或某些列的权限？”

这是我们经常用到的业务场景，比如最典型全公司的短信数据和用户管理平台场景，如何限制各部门仅可查看属于本部门的某些非敏感数据？

PostgreSQL 为了符合各种场景的安全需求，它的权限控制非常完善，它在各个级别上都具有广泛的安全功能。接下来我们来看一下在 PostgreSQL 中利用行级安全和列级安全来解决上述问题。

Everything about database,business.(Most for PostgreSQL). - blog/20170521_01.md at master · digoal/blog