问题标签 [postgresql-performance]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
postgresql - 仅在内存中运行 PostgreSQL
对于我编写的每个单元测试,我想运行一个仅在内存中运行的小型 PostgreSQL 数据库。例如:
理想情况下,我会将一个 postgres 可执行文件签入版本控制,单元测试将使用它。
类似的东西HSQL
,但对于 postgres。我怎样才能做到这一点?
我能得到这样的 Postgres 版本吗?如何指示它不使用磁盘?
postgresql - Linux 上 PostgreSQL 中的配置参数 work_mem
我必须通过调整基本的 PostgreSQL 服务器配置参数来优化查询。在文档中我遇到了这个work_mem
参数。然后我检查了更改此参数将如何影响我的查询性能(使用排序)。我用各种设置测量了查询执行时间,work_mem
非常失望。
我在其上执行查询的表包含 10,000,000 行,并且有 430 MB 的数据要排序。( Sort Method: external merge Disk: 430112kB
)。
,输出为work_mem = 1MB
:EXPLAIN
与work_mem = 5MB
:
与work_mem = 64MB
:
谁能解释为什么性能会变差?或者建议任何其他方法通过更改服务器参数来加快查询执行速度?
我的查询(我知道这不是最佳的,但我必须对这种查询进行基准测试):
完整的执行计划:
database - 防止 PostgreSQL 有时选择错误的查询计划
使用 PostgreSQL 8.4.9 查询的 PostgreSQL 性能有一个奇怪的问题。此查询正在选择 3D 体积内的一组点,使用 aLEFT OUTER JOIN
添加相关 ID 列,其中相关 ID 存在。范围内的微小变化x
会导致 PostgreSQL 选择不同的查询计划,执行时间从 0.01 秒到 50 秒。这是有问题的查询:
该查询需要将近一分钟,如果我添加EXPLAIN
到该查询的前面,似乎正在使用以下查询计划:
但是,如果我将范围内的条件替换为8000
,x
则10644
查询将在几分之一秒内执行并使用以下查询计划:
我远不是解析这些查询计划的专家,但明显的区别似乎是在一个x
范围内它使用 a Hash Left Join
(LEFT OUTER JOIN
非常快),而在另一个范围内它使用 a Nested Loop Left Join
(这似乎非常慢的)。在这两种情况下,查询都会返回大约 90 行。如果我SET ENABLE_NESTLOOP TO FALSE
在查询的慢版本之前这样做,它会非常快,但我知道使用该设置通常是一个坏主意。
例如,我可以创建一个特定的索引以使查询计划者更有可能选择明显更有效的策略吗?谁能建议为什么 PostgreSQL 的查询计划器应该为这些查询之一选择如此糟糕的策略?下面我包含了可能有用的模式的详细信息。
treenode 表有 900,000 行,定义如下:
double3d
复合类型定义如下:
连接中涉及的另外两个表是treenode_class_instance
:
...和class_instance
:
sql - 按 ID 删除数百万行的最佳方法
我需要从我的 PG 数据库中删除大约 200 万行。我有一个需要删除的 ID 列表。但是,我尝试这样做的任何方式都需要几天时间。
我尝试将它们放在一个表中并分批执行 100 个。4 天后,它仍在运行,只删除了 297268 行。(我必须从 ID 表中选择 100 个 ID,删除该列表中的位置,从 ids 表中删除我选择的 100 个)。
我试过:
这也需要永远。很难衡量多长时间,因为在完成之前我看不到它的进展,但查询在 2 天后仍在运行。
当我知道要删除的特定 ID 并且有数百万个 ID 时,只是在寻找从表中删除的最有效方法。
postgresql - 没有 STRICT 修饰符的函数执行得更快?
STRICT
当我在回答这个问题时声明了一个简单的 SQL 函数时,我偶然发现了性能下降。
为了演示,我创建了一个函数的两个变体,按升序对数组的两个元素进行排序。
测试设置
包含 10000 个随机整数对的表 (
STRICT
没有修饰符的函数:
带修饰符的函数STRICT
(其他相同):
结果
我执行了大约 20 次,并从EXPLAIN ANALYZE
.
这些是 Debian Squeeze 上 Postgres 9.0.5 的结果。8.4 上的类似结果。
在所有 NULL 值的测试中,两个函数执行相同:~37 ms。
我做了一些研究,发现了一个有趣的问题。在大多数情况下,声明 SQL 函数STRICT 会禁用函数内联。更多关于PostgreSQL Online Journal或pgsql-performance 邮件列表或Postgres Wiki的信息。
但我不太确定这怎么可能是解释。在这个简单的场景中,不内联函数会导致性能下降?没有索引,没有光盘读取,没有排序。也许通过内联函数简化了重复函数调用的开销?
重新测试
同样的测试,同样的硬件,Postgres 9.1。更大的差异:
相同的测试,新硬件,Postgres 9.6。差距更大,然而:
postgresql - 应用程序中的查询运行时间大不相同
我在使用 PostgreSQL 9 后端的应用程序中遇到了扩展问题。我有一张表,其大小约为 4000 万条记录,并且还在不断增长,并且针对它的条件查询已大大减慢。
为了帮助找出问题所在,我拍摄了数据库的开发快照,并将查询和执行时间转储到日志中。
现在是令人困惑的部分,以及问题的要点....
我在日志中的查询的运行时间与我在 DbVisualizer 中运行“完全相同”的查询以获取解释计划时得到的有很大不同(一个数量级+)。
我说的是“精确”,但真正的区别在于,应用程序使用了一个准备好的语句,我在运行时将值绑定到该语句,而我在 DbVisualizer 中运行的查询已经有了这些值。这些值本身与我从日志中提取的完全相同。
使用准备好的语句能有那么大的不同吗?
postgresql - PostgreSQL 查询使用索引扫描运行得更快,但引擎选择散列连接
查询:
如果我设置SET enable_seqscan = off
,那么它会做的很快,即:
但是如果没有可怕的 enable_seqscan,它会选择做一件更慢的事情:
以下是相关指标:
所以我的问题是,我做错了什么,Postgres 错误地估计了两种加入方式的相对成本?我在成本估算中看到它认为散列连接会更快。它对 index-join 成本的估计降低了 500 倍。
我怎样才能给 Postgres 更多的线索?我确实VACUUM ANALYZE
在运行上述所有内容之前立即运行了。
有趣的是,如果我对游戏数量较少的玩家运行此查询,Postgres 会选择执行索引扫描 + 嵌套循环。因此,关于大量游戏的某些东西会引起这种不受欢迎的行为,即相对估计成本与实际估计成本不一致。
最后,我应该使用 Postgres 吗?我不希望成为数据库调优方面的专家,因此我正在寻找一种数据库,该数据库能够在尽职尽责的开发人员的关注水平下运行得相当好,而不是专门的 DBA。我担心如果我坚持使用 Postgres,我会遇到源源不断的此类问题,这将迫使我成为 Postgres 专家,也许另一个 DB 会更宽容地采用更随意的方法。
Postgres 专家 (RhodiumToad) 审查了我的完整数据库设置 ( http://pastebin.com/77QuiQSp ) 并推荐了set cpu_tuple_cost = 0.1
. 这给了一个戏剧性的加速: http: //pastebin.com/nTHvSHVd
或者,切换到 MySQL 也很好地解决了这个问题。我在我的 OS X 机器上默认安装了 MySQL 和 Postgres,MySQL 的速度提高了 2 倍,通过重复执行查询来比较“预热”的查询。在“冷”查询上,即第一次执行给定查询时,MySQL 的速度要快 5 到 150 倍。冷查询的性能对于我的特定应用程序非常重要。
就我而言,最大的问题仍然悬而未决——Postgres 是否需要更多的摆弄和配置才能比 MySQL 运行得更好?例如,考虑到这里评论者提供的建议都没有奏效。
sql - 使用 PostgreSQL 快速查找相似字符串
我需要在表格中创建类似字符串的排名。
我有下表
目前,我正在使用提供该功能的pg_trgmsimilarity
模块,但我遇到了效率问题。我创建了一个像Postgres 手册建议的索引:
我正在执行以下查询:
查询有效,但是当您有数百个名字时,它真的很慢。此外,也许我忘记了一点 SQL,但我不明白为什么我不能在and sim > .8
没有得到“列 sim 不存在”错误的情况下使用条件。
我想要任何使查询更快的提示。
postgresql - Postgres 表中列的顺序会影响性能吗?
CREATE TABLE
在 Postgres 中,语句中列的顺序会影响性能吗?考虑以下两种情况:
对比
性能foo2
会比foo
列的更好的字节对齐更好吗?当 Postgres 执行时CREATE TABLE
,它是按照指定的列顺序还是按照字节对齐或性能的最佳顺序重新组织列?
ruby-on-rails - 为什么 PostgreSQL 查询在服务器启动后的第一个请求中比在后续请求中慢?
我正在使用 PostgreSQL 9.1.1 和 Rails 3.2.8。使用 NewRelic 的开发模式,我注意到在我的服务器启动或重新启动后的第一个请求期间,几个 SQL 查询所需的时间比后续请求期间要长得多。
有什么理由吗,是因为准备好的陈述吗?