问题标签 [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.
ruby-on-rails - 简单的 Postgres 查询在 Heroku 上运行缓慢
我有一个Movie
包含大约 15,000 个项目的Dvd
模型和一个包含 3500 个项目的模型。
以下查询是使用在 Heroku 上运行的 Crane Postgres 数据库的简单 Rails 关联。我想知道为什么以下查询需要这么长时间,以及我最终如何才能减少它的时间。
postgresql - PostgreSQL 计数查询优化
我在 postgresql 中有一个表,其中包含一个不断更新的数组。
在我的应用程序中,我需要获取该数组列中不存在特定参数的行数。我的查询如下所示:
但是当增加该查询的行数和执行量(每秒几次,可能数百或数千次)时,性能会下降很多,在我看来,postgresql 中的计数可能具有线性执行顺序(我'不完全确定这一点)。
基本上我的问题是:
是否存在适用于这种情况的我不知道的现有模式?什么是最好的方法?
您能给我的任何建议将不胜感激。
database - Postgresql: inner join takes 70 seconds
I have two tables -
Table A : 1MM rows, AsOfDate, Id, BId (foreign key to table B)
Table B : 50k rows, Id, Flag, ValidFrom, ValidTo
Table A contains multiple records per day between 2011/01/01 and 2011/12/31 across 100 BId's. Table B contains multiple non overlapping (between validfrom and validto) records for 100 Bids.
The task of the join will be to return the flag that was active for the BId on the given AsOfDate.
This query takes ~70 seconds on a very high end server (+3Ghz) with 64Gb of memory.
I have indexes on every combination of field as I'm testing this - to no avail.
Indexes : a.AsOfDate, a.AsOfDate+a.bId, a.bid Indexes : b.bid, b.bid+b.validfrom
Also tried the range queries suggested below (62seconds)
This same query on the free version of Sql Server running in a VM takes ~1 second to complete.
any ideas?
Postgres 9.2
Query Plan
see http://explain.depesz.com/s/1c5 for the analyze output
postgresql - 在大分区中执行缓慢的查询
我有一个在时间戳字段上分区的数据库模式,每个分区包括 155 个时间戳唯一值,大小为 1.5 GB。架构非常简单,包括时间戳、对象 ID 和其他字段(无外键无连接)。主键是时间戳和对象 ID 字段。
现在以下查询需要大约 50 秒才能执行
条件中的时间跨度涵盖144个时间点
执行计划如下:
如何加快此查询的执行速度(在不到 10 秒内执行)
sql - 用 INSERT / UPDATE 的单个查询替换循环
我正在 PostgreSQL 中编写一个函数。它基本上做了3个步骤:
- 从源表中获取记录。
- 检查目标表中获取的记录的值,如果在目标表中找到记录,则用获取的记录更新目标表的所有值,否则将获取的记录插入目标表。
如果我为插入/更新编写单个查询,而不是执行此循环,它会比上述方法更快吗?如何通过编写单个查询而不是遍历每条记录并进行更新/插入来获得相同的结果。
我目前的方法如下
sql - 提高查询速度:大 postgres 表中的简单 SELECT
我在 Postgres 数据库上的 SELECT 查询中遇到了速度问题。
我有一个表,其中有两个整数列作为键: (int1,int2) 这个表有大约 7000 万行。
我需要在这种环境中进行两种简单的 SELECT 查询:
这两个选择返回这 7000 万行中的大约 10.000 行。为了尽可能快地工作,我考虑使用两个 HASH 索引,每列一个。不幸的是,结果并不是那么好:
这是这些查询之一的 EXPLAIN ANALYZE 示例。大约需要 23 秒。我的期望是在不到一秒钟的时间内获得这些信息。
这些是 postgres db 配置的一些参数:
任何帮助、评论或想法将不胜感激。
先感谢您。
sql - PostgreSQL查询效率
我正在使用 PostgreSQL(我是数据库领域的新手),我想知道您对我在使用的代码中发现的此类查询的效率的看法。这些查询有很多 JOIN,其中一个(粗体)按请求有很多行。这迫使我们 GROUP BY request.id 以便按请求获取行和包含所有这些行数据的字段(粗体)。
我认为这种查询必须花费大量时间来寻找所有这些最大值,但我想不出另一种方法来做到这一点。关于其效率以及如何改进它的任何想法?
解释返回this。
sql - Postgres 更新 x WHERE id IN y
以前可能有人问过这个问题,但是在谷歌上搜索“IN”之类的关键字效果并不好。
这是我的查询:
将其分解:我想将出现在订单表中的所有客户的所有客户的类型(只是一个 int)设置为 2,位于任一列中。
在我的测试数据中,这些表中没有一个包含超过几百行,但是查询运行了很多分钟(即使没有 UNION,这似乎也没有太大区别),显然是重新执行内部查询在客户中每行一次。我显然可以将它重写为一个 SELECT DISTINCT(id),然后进行几百次单行更新,并以我用于 ODBC 访问的任何语言执行逻辑,但这只是一个 hack。
我怎样才能正确地重写它?
附录:我要更新的表包含很多相对较大的 BYTEA blob,每行几 MB。它们设置为外部存储或扩展,但我想知道这是否会使顺序扫描变慢。所有更新似乎都需要很长时间,而不仅仅是这个。
performance - PostgreSQL 查询耗时过长
我有几亿行的数据库。我正在运行以下查询:
当 where 子句在数据库中找到匹配项时,我会在几毫秒内得到结果,但如果我修改查询并r."Name"
在 where 子句中指定一个不存在的,则需要花费太多时间才能完成。我猜 PostgreSQL 正在对Payments
表(包含最多行)进行顺序扫描,逐行比较每一行。
postgresql 不够聪明,无法首先检查Roles
表是否包含任何行Name
'Moses'
吗?
Roles 表仅包含 15 行,而 Payments 包含约 3.5 亿行。
我正在运行 PostgreSQL 9.2.1。
顺便说一句,在 MS SQL Server 上完成对相同架构/数据的相同查询需要 0.024 毫秒。
我将在几个小时内更新问题并发布 EXPLAIN ANALYZE 数据。
Here'e解释分析结果:http ://explain.depesz.com/s/7e7
这是服务器配置:
我在 i5 cpu(4 核,3.3 GHz)、8 GB RAM 和 Crucial m4 SSD 128GB 上运行 postgresql
更新 这看起来像是查询计划器中的一个错误。在 Erwin Brandstetter 的推荐下,我将它报告给了Postgresql 错误邮件列表。
postgresql - 为什么这个查询会导致顺序扫描?
我对 PostgreSQL 很陌生,如果我不清楚一些明显的事情,请原谅我。我有一个数据库,其中约 4.5 亿行分布在 6 个表中(每个表都有主键)。当我运行以下查询时:
po."Id" 是主键。我只是 VACUUM ANALYZED 整个数据库。您可以在此处查看解释分析详细信息。PaymentOrders 表包含 4000 万行,而 Payments 包含 3.5 亿行。我在 Windows 8 机器、I5 CPU(4 核 3.3GHz)、8GB RAM 上运行 x64 PostgreSQL 9.2。你也可以在这里看到我的 postgresql.conf 文件。
任何人都知道为什么此查询会导致对 Payments 表进行顺序扫描?是我做错了什么还是 PostgreSQL 有一些严重的缺陷?我开始严重怀疑 PostgreSQL 查询计划器...