postgresql好慢的简单介绍

为什么安装过postgresql后开机很慢

把所有开机自动运行的软件都禁止掉。用360安全卫士或者别的软件都可以。当然，杀毒软件肯定要设置成开机自动启动。

创新互联公司电话联系：13518219792，为您提供成都网站建设网页设计及定制高端网站建设服务，创新互联公司网页制作领域10余年，包括成都围栏护栏等多个方面拥有丰富的网站营销经验，选择创新互联公司，为企业锦上添花！

以360安全卫士为例：下载360安全卫士，依次打开：360安全卫士--高级工具--开机加速。注意，只留下360建议开启的项目，其他的可以全部禁止掉。我的现在开机最快29秒。

为什么我在postgresql的json数据中查询，速度会比mysql慢很多

PostgreSQL 9.4 引入了jsonb，一个新的列类型用于存储文档到你的关系数据库中。jsonb和json在更高的层面上看起来几乎是一样的，但在存储实现上是不同的。使用jsonb的优势在于你可以轻易的整合关系型数据和非关系型数据，在性能方面，可以比大多数类似于MongoDB这样的非关系数据库更好理解json和jsonb之间的不同因此，两种列类型之间的区别是什么？当我们比较写入数据速度时，由于数据存储的方式的原因，jsonb会比json稍微的慢一点。json存储完整复制过来的文本输入，必须一遍又一遍的解析在你调用任何函数的时候。它不支持索引，但你可以为查询创建表达式索引。jsonb存储的二进制格式，避免了重新解析数据结构。它支持索引，这意味着你可以不使用指定的索引就能查询任何路径。其他的不同包括，json列会每次都解析存储的值，这意味着键的顺序要和输入的时候一样。但jsonb不同，以二进制格式存储且不保证键的顺序。因此，如果你有软件需要依赖键的顺序，jsonb可能不是你的应用的最佳选择。

Postgresql慢查询原因查找

这个在开发环境上是好的，而在运营中慢的话。而且你的描述中说明服务器的性能是好的，那么一般就是你的这个表的数据分布不均匀。

为什么PG的delete慢

ref:

要删除的表 articles ， articles 中有一个字段是表 comments 的外键，即：

最简单的办法就是在确认没有错误的情况下，disable trigger，删完后再打开。但是还有一种可能性就是在删除的时候PG会去关联的表中查找有没有关联的记录，本例中就是在删除articles中的东西时会在comments中按article_id查找，如果article_id在此时没有加索引，而且comments和articles表中都有大量数据的时候，就会出现很慢的情况。解决方案就是给comments表中的article_id加上index

postgresql 进程出现waiting导致网站响应慢，请问如何解决

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语句再查原因可能会准确些。