问题标签 [postgresql-performance]

我是 PostgreSQL 的新手。有没有办法提高以下查询的执行时间：

我还没有找到如何将LIMIT子句插入聚合调用，作为排序。

table 中有created( timestamp) 和site_id( )的索引，但是很遗憾，没有to的外键。该查询旨在返回一个站点列表，其中包含 5 个最近创建的页面的子列表。integerpagessites.idpages.site_id

PostgreSQL 版本是 9.1.5。

我有一个大报告表。位图堆扫描步骤需要 5 秒以上。

有什么我可以做的吗？我向表中添加列，重新索引它使用的索引会有所帮助吗？

我对数据进行联合和求和，所以我不会将 500K 记录返回给客户端。
我使用postgres 9.1。
这里解释一下：

询问：

表：
foo是text具有 4 个不同值的字段。
foo_id目前bigint有 10K 个不同的值。

我在云服务器上运行 Postgres 9.1（我知道这远非理想，我们希望在今年的某个时候进行迁移）。该服务器经常对超过 300 万条记录的表执行全文查询。这是一个典型查询的示例。

datepublished、hide 和 tsvall 列都已编入索引，tsvall 使用 GIN 编入索引。postgres 配置设置 shared_buffers、effective_cache_size、work_mem 也进行了调整。

对于一个典型的查询（使用的查询文本是“august”），使用上面示例中的参数返回 986 行需要 5 秒。我真的很想加快速度。非常感谢您的帮助，我可以根据要求提供额外的信息。

--编辑：解释分析结果

这是评论中要求的链接http://explain.depesz.com/s/QDAb

--编辑2

我意识到我的 datepublished 索引没有排序，所以我在按 DESC 排序的列上创建了一个（btree）索引。这是我现在得到的 EXPLAIN ANALYZE 输出示例

这里又是请求的链接http://explain.depesz.com/s/Ksss

标记

这个简单的语句似乎运行了很长时间，我该如何更改 sql 以便它可以运行得更快？谢谢。

我有一个包含日期时间字段“updated_at”的表。我的很多查询将使用范围查询来查询该字段，例如 update_at > 某个日期的行。

我已经为 updated_at 添加了一个索引，但我的大多数查询仍然很慢，即使我对返回的行数有限制。

我还能做些什么来优化查询日期时间字段的查询？

我有一个包含大量记录的表，但其中只有一部分在任何时候都是“活动的”，我的网络应用程序只需要引用这些记录。我有一个每晚运行的更新过程，它会添加新的（活动的）记录，并可能重新激活旧的记录。

postgres 是否能够确定它应该缓存活动记录？如果没有，我应该将活动记录移动到新表以帮助它 - 还是有其他方式给它一个“提示”？

更新 - 活动记录由名为 end_date 的日期时间字段中的 NULL 值指示

谢谢

现在，我正在通过 PgPool 测试从应用程序到 PPAS 的查询。

当我查询

...或更新/插入，我必须等待很长时间（30 --> 60 秒）。

我检查了我的 PPAS 日志文件，但找不到有关此查询的任何信息。

例子：

• 询问 （*）
• 等待30秒后完成。
• 查看日志文件（看不到任何信息）

我用另一个查询进行了测试，没关系，我可以在日志文件中找到信息。

我有一张这样的桌子。

下面是一些示例数据。

我需要上表中以下格式的数据。

因此基本上需要每个日期的每个事件的计数。

我已尝试以下查询以获得所需的结果。

有人可以建议我找出更好和优化的查询吗？，或者我正在遵循一个好的方法。

I have an iPhone app connected to a Django server running on Heroku. The user taps a word (like "cape") and then queries the server for any other passages containing that word. So right now I do a SQL query with some RegEx:

SELECT "connectr_passage"."id", "connectr_passage"."third_party_id", "connectr_passage"."third_party_created", "connectr_passage"."source", "connectr_passage"."text", "connectr_passage"."author", "connectr_passage"."raw_data", "connectr_passage"."retweet_count", "connectr_passage"."favorited_count", "connectr_passage"."lang", "connectr_passage"."location", "connectr_passage"."author_followers_count", "connectr_passage"."created", "connectr_passage"."modified" FROM "connectr_passage" WHERE ("connectr_passage"."text" ~ E'(?i)\ycape\y' AND NOT ("connectr_passage"."text" ~ E'https?://' ))

on a table with about 412K rows of data, using the $9 'dev' database, this query takes 1320 ms So for the app user it feels pretty slow as the total response time is even higher.

With the same exact database on my local machine (MBP, 8gb ram, ssd), this query takes 629.214 ms

I understand the dev database has some limitations (doesn't do in-memory cache and such), so my questions are:

1. Is there some way I can speed things up? Adding an index on the text column didn't seem to help.

2. Will upgrading to one of the production databases significantly improve this performance? They're pretty expensive for my needs.

3. Any other good alternatives for hosting a database connected to Heroku that you know about?

4. Any recommended alternatives to doing a regex sql query to search for terms? I was thinking about creating a custom index store of words or something, maybe there's a plugin for that somewhere. Haystack?

----- Edit -----

Here is what the elephant has to say about my query:

So it looks like it is doing a full table scan, so the index isn't working. I'm a Postgres newbie so not sure if I have this right, but here is my index (created by setting db_index=True in the Django model):

Another edit:

Here is the latest - after using the pg_trgm add-on.

First attempt:

Damn, still super slow. But wait what if I do a simple filter before the RegEx:

Superfast!

我有一个vote_pairs看起来像这样的视图：

而且，表中有大约 100k 行votes，跨该视图的查询大约需要 3 秒才能执行。

但是，当我在名称上添加额外的过滤器时：

运行时间翻了两番，完成查询需要将近 12 秒vote_pairs。

无论限制的位置如何，此运行时都是一致的……例如，如果将过滤器移动到WHERE外部查询的子句，则查询同样慢：

这是怎么回事？Postgres中的字典比较慢吗？这是别的吗？我怎样才能提高这个查询的速度？

投票表：

EXPLAIN ANALYZE没有名称过滤器的输出：

并使用过滤器：

解释（分析，缓冲区）：

杂项说明：

• VACCUM FULL并且ANALYZE votes已经运行
• 8.4.11 和 9.2.3 的行为方式相同