问题标签 [postgresql-performance]

以下查询在 1.5 秒内完成（没关系，该表包含大约 500M 行）：

查询计划：http ://explain.depesz.com/s/8Ix

相反，搜索 product.name 会将运行时间增加到完全不可接受的 200 秒：

查询计划：http ://explain.depesz.com/s/0RfQ

请注意，名为“new00000006”的产品的 id 为 24（与上面的快速查询中的 id 相同）。证明：

为什么该查询比第一个查询花费 200 倍的时间？

这个查询的另一个有趣的修改是 this.. 而不是 product.id = 24（就像在第一个查询中一样），我使用 product.id = (select 24)。这也需要 200 秒才能运行（它实际上会导致与搜索 product.name 时相同的错误查询计划）：

查询计划：http ://explain.depesz.com/s/K3VO

统计表显示产品 id 24 是“稀有”：

产品 id 24 的频率为 6.7e-005（它是“新产品”），而旧产品的频率约为 0.01。

统计数据表明，第一个查询计划（在 1.5 秒内运行的那个）非常有意义。它使用 sales_productid_index 快速查找该产品的销售额。为什么在其他两种情况下不使用相同的查询计划？似乎忽略了统计数据。

表定义（稍微混淆/重命名）：

版本：PostgreSQL 9.3.1，由 Visual C++ build 1600 编译，64 位

配置：除maintenance_work_mem外的默认配置，已增加到1GB。

操作系统：Microsoft Windows [版本 6.2.9200]

安装的 RAM 数量和大小：32GB

存储：单个 1TB SSD

我有一张大桌子：

90% 的请求是关于 a 过去 2-3 天的订单person_id，例如：

我怎样才能提高性能？

我知道Partitioning，但是现有的行呢？看起来我需要INHERITS每 2-3 天手动创建一次表。

我有一个（可能）关于 Postgres 如何执行包含WITH子句的查询的基本问题。我想知道是否在WITH子句中包含无关表实际上会减慢查询速度。也就是说，如果在WITH子句中创建的“临时”表从未在子句之外调用WITH，那么该“临时”表是否真的创建了？

在第一个示例中，我加入了两个使用WITH子句创建的“临时”表：

在第二个示例中，我正在执行完全相同的查询，只是在WITH子句中创建了一个无关的表“temp3”。

这两个查询之间有任何性能差异吗？如果table_3是一个巨大的表，这会减慢示例 2 与示例 1 中的查询吗？如果不是，为什么不呢？

好像不影响查询时间。不过我还是很好奇为什么...

下面的 SQL 查询非常慢：

在 100 亿条产品记录中，可能只有 100 条产品没有对应的交易记录。

此查询非常慢，因为我怀疑它正在执行全表扫描以查找那些空外键产品记录。

我想创建一个像这样的部分索引：

以上是可能的，我将如何去做？

注：该数据集的一些特征：

1. 交易永远不会被删除，只会被添加。

2. 产品永远不会被删除，而是以每分钟 100 次的速度添加（显然这是一个复杂得多的实际用例背后的虚构示例）。其中一小部分是暂时的孤儿

3. 我需要经常查询（最多每分钟一次）并且需要始终知道当前的孤立产品集是什么

这个问题涉及到这个问题：How to speed up inserting performance in PostgreSQL

所以，我有一个 java 应用程序，它在数据库中做了很多（大约十亿）插入PostgreSQL操作。它打开几个到同一个数据库的 JDBC 连接，以并行执行这些插入。正如我在提到的问答中所读到的：

从多个连接并行插入或复制。多少取决于硬件的磁盘子系统；根据经验，如果使用直连存储，您需要每个物理硬盘驱动器一个连接。

但就我而言，我的数据库只有一个磁盘存储。

所以，我的问题是：在这种情况下打开多个连接真的有意义吗？由于 I/O 操作竞争，它会降低性能而不是期望增加吗？

为了澄清起见，这是带有实际postgresql流程负载的图片：

比较 hstore 性能的完全假设的问题是 postgress 假设每个用户都有一个关注者列表。有两种实现方式

1. 与“关注者”表的多对多关系（ user_id，follower_id ）
2. 一个 hstore 列，其中的值是关注者的 id。（带有 GiST 索引）

如果我想找到关注某个用户的所有用户，哪个版本会执行得更快？

1. SELECT follower_id from follower where user_id = '1234'
2. SELECT user_id from user where (data @> 'followers=>'1234')

在现实生活中，对于选项 b，我们可能还会维护用户关注的所有用户的列表——为了这个问题，假设我们不这样做。

我有桌子员工，桌子运动有 n 到 m 关系，这意味着，我还有一张桌子，比如说桌子 emp_sport

表员工

我想像这样从员工中选择数据

结果，我有

问题是，当我在表员工和 emp_sport 中有非常大的数据时，查询非常慢。

我正在尝试使用ST_SnapToGrid，然后GROUP BY使用网格单元（x，y）。这是我首先做的：

我不想ST_SnapToGrid为x和重新计算y。所以我将其更改为使用子查询：

但是当我运行时EXPLAIN，这两个查询都有完全相同的执行计划：

问题：PostgreSQL 会重用 的结果值ST_SnapToGrid()吗？
如果没有，有没有办法让它做到这一点？

我有一个 3M 行的表。

我想检索所有这些行并使用dc.js.

我遇到的问题是，对于单个列，它需要大约 70 秒。

如果我编写查询，检索这些行大约需要 240 秒。

我在这样的列上使用选择查询。

而已。没有分组，什么都没有。

但这需要很多时间。

听说过索引，我为我使用的列创建了一个索引。但即使没有丰硕的成果。

I have four tables: families, parents, children, clubs. families have many parents and many children. The children have many clubs memberships.

I would like to create a "view" for fast searching names and email addresses that returns the each of the parents and children, names, email address, along with all an array of all the ids that of all the clubs that their children belong.

Here's what I have so far for the query I would like to be in the view:

Question's are:

• How do I get rid of duplicate club_ids for children and parents?

• It's a really slow query. If it is indexed, will the view be updated every time a write happens on child or parent?

• Here is the execution plan: http://explain.depesz.com/s/BA9

• Here is a sqlfiddle: http://sqlfiddle.com/#!15/9c737/2