13518219792
PostgreSQL以下简写为PG。PG在WIN下跑性能差是因为PG在WIN下时，实际是在一个UNIX的仿真器上运行的，倒不是说WIN真的不行。目前用PG做应用必须在UNIX类的系统上搞。至于具体用什么系统，我个人觉得用LINUX简单点，因为FREEBSD缺省时不支持SYSV的系统调用。所以安装配置上就复杂了些。硬件嘛，我看不用什么IBM、SUN、HP或DEC一类的了，那不合使用PG的本意，如果你有钱买那些东西，也就不要用PG了，还是用ORACLE吧。同时，如果你的数据库规模不是太大（100G以内）也不一定非用64位的机器，不过SCSI硬盘是一定要的，能做RAID就更好了，一般为省点钱做个条带效果比较明显。
10年积累的网站设计制作、网站设计经验，可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你，你也不认识我。但先网站制作后付款的网站建设流程，更有道县免费网站建设让你可以放心的选择与我们合作。
一、PostgreSQL的稳定性极强，Innodb等引擎在崩溃、断电之类的灾难场景下抗打击能力有了长足进步，然而很多MySQL用户都遇到过Server级的数据库丢失的场景——mysql系统库是MyISAM的，相比之下，PG数据库这方面要好一些。二、任何系统都有它的性能极限，在高并发读写，负载逼近极限下，PG的性能指标仍可以维持双曲线甚至对数曲线，到顶峰之后不再下降，而MySQL明显出现一个波峰后下滑（5.5版本之后，在企业级版本中有个插件可以改善很多，不过需要付费）。
近些年对数据库内核的研究与开发多集中于存储引擎层面，对查询优化器进行深入分析的少之又少，更不用谈与之相关的书籍，本书很好地弥补了这一空白。相信包括我在内的很多数据库开发人员都非常想知道数据库查询优化器的底层实现，本书不仅完成了对PostgreSQL查询优化器的分析，同时也完成了对MySQL查询优化器的分析，此外还对比了两种数据库的不同实现，内容夯实有力，相信对从事数据库相关工作的人员来说会有极大的帮助。
1。打开psql界面，输入以下：
SELECT pg_stat_get_backend_pid(s.backendid) AS procpid,
pg_stat_get_backend_activity(s.backendid) AS current_query
FROM (SELECT pg_stat_get_backend_idset() AS backendid) AS s;
2。同时监视你的数据库服务器什么时候发生update waitting状况，一旦发现，立刻记录下它的进程号。
3。迅速把第1步里的语句按回车执行了，查看结果。结果是一个view，结构大致如下：
procpid | current_query
---------+-------------------------------------------------------------------
26574 | IDLE
26640 | IDLE
26643 | IDLE
26651 | IDLE
26646 | IDLE
26649 | IDLE
26654 | IDLE
26657 | IDLE in transaction
26659 | IDLE
26674 | IDLE
23623 | IDLE
26824 | SELECT pg_stat_get_backend_pid(s.backendid) AS procpid,
: pg_stat_get_backend_activity(s.backendid) AS current_query
: FROM (SELECT pg_stat_get_backend_idset() AS backendid) AS s;
26901 | IDLE
（这是我目前开发机器上的结果，没有正在执行的语句，如果有，IDLE就会是SQL语句，最下面的哪条是这个性能执行查询自身的语句）
你把左侧一列的procpid号对应上在第2步中查到的进程号，然后把对应上的current_query 发出来，让大家帮你看看是哪句update语句执行了过长的时间，针对这条update语句再查原因可能会准确些。
一、使用EXPLAIN：
PostgreSQL为每个查询都生成一个查询规划，因为选择正确的查询路径对性能的影响是极为关键的。PostgreSQL本身已经包含了一个规划器用于寻找最优规划，我们可以通过使用EXPLAIN命令来查看规划器为每个查询生成的查询规划。
PostgreSQL中生成的查询规划是由1到n个规划节点构成的规划树，其中最底层的节点为表扫描节点，用于从数据表中返回检索出的数据行。然而，不同
的扫描节点类型代表着不同的表访问模式，如：顺序扫描、索引扫描，以及位图索引扫描等。如果查询仍然需要连接、聚集、排序，或者是对原始行的其它操作，那
么就会在扫描节点"之上"有其它额外的节点。并且这些操作通常都有多种方法，因此在这些位置也有可能出现不同的节点类型。EXPLAIN将为规划树中的每
个节点都输出一行信息，显示基本的节点类型和规划器为执行这个规划节点计算出的预计开销值。第一行(最上层的节点)是对该规划的总执行开销的预计，这个数
值就是规划器试图最小化的数值。
这里有一个简单的例子，如下：
复制代码 代码如下:
EXPLAIN SELECT * FROM tenk1;
QUERY PLAN
-------------------------------------------------------------
Seq Scan on tenk1 (cost=0.00..458.00 rows=10000 width=244)
EXPLAIN引用的数据是：
1). 预计的启动开销(在输出扫描开始之前消耗的时间，比如在一个排序节点里做排续的时间)。
2). 预计的总开销。
3). 预计的该规划节点输出的行数。
4). 预计的该规划节点的行平均宽度(单位：字节)。
这里开销(cost)的计算单位是磁盘页面的存取数量，如1.0将表示一次顺序的磁盘页面读取。其中上层节点的开销将包括其所有子节点的开销。这里的输出
行数(rows)并不是规划节点处理/扫描的行数，通常会更少一些。一般而言，顶层的行预计数量会更接近于查询实际返回的行数。
现在我们执行下面基于系统表的查询：
复制代码 代码如下:
SELECT relpages, reltuples FROM pg_class WHERE relname = 'tenk1';
从查询结果中可以看出tenk1表占有358个磁盘页面和10000条记录，然而为了计算cost的值，我们仍然需要知道另外一个系统参数值。
复制代码 代码如下:
postgres=# show cpu_tuple_cost;
cpu_tuple_cost
----------------
0.01
(1 row)
cost = 358(磁盘页面数) + 10000(行数) * 0.01(cpu_tuple_cost系统参数值)
下面我们再来看一个带有WHERE条件的查询规划。
复制代码 代码如下:
EXPLAIN SELECT * FROM tenk1 WHERE unique1 7000;
QUERY PLAN
------------------------------------------------------------
Seq Scan on tenk1 (cost=0.00..483.00 rows=7033 width=244)
Filter: (unique1 7000)
EXPLAIN的输出显示，WHERE子句被当作一个"filter"应用，这表示该规划节点将扫描表中的每一行数据，之后再判定它们是否符合过滤的条
件，最后仅输出通过过滤条件的行数。这里由于WHERE子句的存在，预计的输出行数减少了。即便如此，扫描仍将访问所有10000行数据，因此开销并没有
真正降低，实际上它还增加了一些因数据过滤而产生的额外CPU开销。
上面的数据只是一个预计数字，即使是在每次执行ANALYZE命令之后也会随之改变，因为ANALYZE生成的统计数据是通过从该表中随机抽取的样本计算的。
如果我们将上面查询的条件设置的更为严格一些的话，将会得到不同的查询规划，如：
复制代码 代码如下:
EXPLAIN SELECT * FROM tenk1 WHERE unique1 100;
QUERY PLAN
