问题标签 [postgresql-performance]

我在 PostgreSQL 中有下表：

我做了以下选择：

执行计划的解释如下：

据我了解，这是全表扫描。问题是：为什么不使用我的索引？

可能是，原因是我的表中的行太少？我只有20个。您能否为我提供一条 SQL 语句，以便用随机数据轻松填充我的表以检查索引问题？

我找到了这篇文章：http: //it.toolbox.com/blogs/db2luw/how-to-easily-populate-a-table-with-random-data-7888，但它对我不起作用。语句的效率并不重要，重要的是简单性。

考虑：

Postgres 不使用索引来进行搜索。使用排序规则"POSIX"时，Postgres 使用索引：http ://sqlfiddle.com/#!12/ed1cc/1

使用排序规则"en_US"时，Postgres 使用顺序扫描：http ://sqlfiddle.com/#!12/efb18/1

为什么有区别？

我有一个这样的查询

通常有 9-10 个这样的连接。它运行得非常非常慢。我在 person_func(person_id)、person_location(person_id) 上添加了索引，但没有帮助。我可以做些什么来优化它？

一个例子 - SQLFiddle 例子

给定下表：

我想查询每个 (user_id, month_d) 对的最后 6 个月的累积计数。我可以通过以下 JOIN 来做到这一点：

但我想知道这是否可以用窗口函数解决？

样本数据：

预期结果（来自上面的连接）：

我使用数据库来表示文件列表，以及与每个文件相关联的一些元数据。我需要定期更新这个文件列表，只添加新文件并删除不再存在的文件（我不必触摸表中的现有行，因为我会丢失相关的元数据）。

当我有大约 10000 个文件时，我当前的查询只需要几秒钟，但我当前的 150000 个文件表需要一个小时。

经过网上的一些研究，我一直是以下过程：

1. 使用扫描结果填充表“newfiles”
2. DELETE FROM files WHERE path NOT IN (SELECT path FROM newfiles);
3. INSERT INTO files (SELECT * FROM newfiles WHERE path NOT IN (SELECT path FROM files));

我也有索引：

（我主要使用这些索引在数据库中进行搜索；我的应用程序在文件中有一个搜索引擎。）

当我有 150000 个文件时，这两个查询中的每一个都需要一个多小时。我该如何优化呢？

谢谢你。

使用上面的代码，我可以将确切的城市添加到 GPS 点。它在 5000 万行上运行大约 45-50 分钟。“城市”表中大约有 4000 个城市需要检查。

我有另一个形状文件，其中包含给定国家/地区的 19 个县（只有 1 个国家/地区）。将县添加到点大约需要 1.5 小时。

我有 52 个欧盟国家的第三个形状文件。它使用相同的 sql 查询运行了将近 25 个小时。

每个表都有 geom 索引，例如：

问：为什么只检查几个多边形就这么慢？

解释分析：

I need help in optimize a PostgreSQL query which uses the BETWEEN clause with a timestamp field.

I have 2 tables:

containing about 3394 rows

containing about 4000000 rows

There are btree indexes on both PKs id_one and id_two, on the FK id_one and cut_time.

I want to perform a query like:

This query retrieves about 1.700.000 rows in about 7 seconds.

Below the explain analyze report is reported:

The index on the timestamp column isn't used. How to optimize this query?

我的 PostgreSQL 数据库中有这 3 个表：

• 艺术家：身份证，姓名
• 专辑： id，标题，年份，artist_id
• 歌曲： id，标题，album_id

基本上每个艺术家都有多张专辑，每张专辑都有多首歌曲。

我的查询正确返回了 25 个不同的 Artist.id，他们有一首歌曲的标题以“The”开头，按专辑年份排序：

然而，它是缓慢且低效的，因为最里面的查询没有限制，因此它将搜索整个表以查找所有可能的匹配项。理想情况下，当找到 25 个不同的艺术家 ID 时，它会停止搜索。

可以重写或优化此查询以更快地执行吗？

我认为窗口函数可以在这里加快速度，但我一直无法找出可行的方法。

谢谢！

我们在 RedHat 中使用 Postgres 9.2。我们有一个类似于以下的表：

作为批处理作业的一部分，我们首先使用新的 BULK_ID 向表中添加一些行。所有新记录的 CHUNK_ID = NULL，STATE = 'PENDING'。插入在 500K 到 150 万行之间。发生这种情况时表的大小超过 15M 记录。

插入后，我们开始分块处理表。为此，我们首先为下一个块选择一些项目，然后处理它们。通过以下查询选择项目：

$1每次块迭代都会增加，$2和$3始终相同（刚刚插入的 BULK_ID），$4通常在 2,000 到 10,000 之间。

问题是前几个块需要很长时间才能更新。例如，对于 2000 的限制，大多数更新发生在 1 秒内，而前几个更新需要 2 分钟以上。

我们正试图了解为什么会发生这种情况以及如何解决它。阅读文档后：

为了确保数据页的一致性，在每个检查点之后对数据页的第一次修改会导致记录整个页面内容。

我们认为它与检查站和 WAL 有关，但我们无法确定它。

有什么建议么？

如果我创建一个循环执行一堆动态查询的函数，处理时间似乎会成倍增加。举个例子，我将使用以下代码。请记住，我必须在我的代码中使用执行语句。

如果我的 for 语句循环 10 次，则需要 125 毫秒才能完成。如果我的 for 语句循环 100 次，则需要 4,250 毫秒才能完成。

有没有我可以使用的设置，以便在 1,250 毫秒内完成 100 次循环？

编辑：更多信息

每个执行查询都在进行仅索引扫描。这是计划。

编辑2：

我用plperl重写了这个函数。当我在 100x 执行查询上使用“spi_exec_query()”时，它运行了 4,250 毫秒。当我在 100 倍执行查询上使用“spi_query()”时，它在 1,250 毫秒内运行 - 消除了指数增长。