相关疑难解决方法(0)

假设我有一个包含字段A和的表B。我在A+上进行常规查询B，所以我在 上创建了一个复合索引(A,B)。A复合索引是否也会对查询进行全面优化？

此外，我在 上创建了一个索引A，但 Postgres 仍然只使用复合索引来查询A。如果前面的答案是肯定的，我想这并不重要，但是为什么它默认选择复合索引，如果单个A索引可用？

我在 PostgreSQL 9.0.8 中有一个很大的对象表（15M+ 行），我想查询过时的字段。

出于可扩展性和并发性的目的，我想将查询除以数百万，并且我想获取具有几天前日期的 updated_at 字段的所有数据。

我已经在 100 万个 ID 上尝试了许多索引和查询，但使用 Heroku 的 Ronin 硬件似乎无法在 100 秒内获得性能。

我正在寻找我尚未尝试使其尽可能高效的建议。

尝试 #1

 EXPLAIN ANALYZE SELECT count(*) FROM objects
 WHERE (date(updated_at)) < (date(now())-7) AND id >= 5000001 AND id < 6000001;
 INDEX USED: (date(updated_at),id)
 268578.934 ms

尝试 #2

 EXPLAIN ANALYZE SELECT count(*) FROM objects
 WHERE ((date(now()) - (date(updated_at)) > 7)) AND id >= 5000001 AND id < 6000001;
 INDEX USED: primary key
 335555.144 ms

尝试 #3

 EXPLAIN ANALYZE SELECT count(*) FROM …

我有很多看起来像这样的表格：

CREATE TABLE table1(id INTEGER PRIMARY KEY, t1c1 INTEGER, t1c2 INTEGER);
CREATE TABLE table2(id INTEGER PRIMARY KEY, t1 INTEGER REFERENCES table1(id), t2c1 INTEGER);

我做了很多连接，我试图过滤连接表以从第一个表中获取内容，如下所示：

SELECT t1c1
FROM table1
JOIN table2 ON table2.t1 = table1.id
WHERE t2c1 = 42;

当我为表编写索引时，我会查看 WHERE 子句中使用的列并构建索引以满足它们。所以对于这个查询，我最终会写一个这样的索引：

CREATE INDEX ON table2 (t2c1);

并且这个索引至少有资格在该查询中使用。

我的问题是，如果我写这样的索引：

CREATE INDEX ON table2 (t2c1, t1);

索引会不会作为覆盖索引来帮助上面查询中的JOIN？我应该改变我的索引编写策略来覆盖外键列吗？

我正在使用 postgres 9.4。

的messages具有以下模式：消息属于FEED_ID，并且具有posted_at，还消息可以具有（在答复的情况）的父消息。

                    Table "public.messages"
            Column            |            Type             | Modifiers
------------------------------+-----------------------------+-----------
 message_id                   | character varying(255)      | not null
 feed_id                      | integer                     |
 parent_id                    | character varying(255)      |
 posted_at                    | timestamp without time zone |
 share_count                  | integer                     |
Indexes:
    "messages_pkey" PRIMARY KEY, btree (message_id)
    "index_messages_on_feed_id_posted_at" btree (feed_id, posted_at DESC NULLS LAST)

我想返回由 排序的所有消息share_count，但对于每个parent_id，我只想返回一条消息。即，如果多条消息具有相同的parent_id，则仅posted_at返回最新的一条 ( )。在parent_id可以为空，以空消息parent_id都应该回报。

我使用的查询是：

WITH filtered_messages AS (SELECT * 
                           FROM messages
                           WHERE feed_id …

我在 BRIN 索引的 OLAP 查询中发现了许多用例，因为它们要小得多，并且速度与 BTREE 索引处于同一数量级。

通常，我使用 BRIN 索引来单调（或接近）增加时间戳列。在我们的 OLTP 数据库中，它们紧密地放置在磁盘上，因为随着时间的推移，它们自然会按顺序写入。

在我们的仓储 Postgres 实例中，表的某些部分是大批量加载的，不一定按时间排序。

是否有一些分析查询可以告诉我数据是否放置得太随机而无法使用 BRIN，即使列值分布似乎应该遵循创建 BRIN 索引的所有先决条件？

这是一个非常有趣的问题（针对 SQL Server 提出的问题），我想尝试一下，看看它是如何在 PostgreSQL 中完成的。让我们看看其他人是否可以做得更好。拿着这个数据，

CREATE TABLE foo
AS
  SELECT pkid::int, numvalue::int, groupid::int
  FROM ( VALUES
    ( 1,  -1   , 1 ),
    ( 2,  -2   , 1 ),
    ( 3,  5    , 1 ),
    ( 4,  -7   , 1 ),
    ( 5,  1    , 2 )
  ) AS t(pkid, numvalue, groupid);

我们正在尝试生成这个：

PKID   RollingSum    GroupID
----------------------------- ## Explanation: 
1      0             1        ## 0 - 1 < 0  => 0
2      0             1        ## 0 - 2 < 0 …

架构：

  CREATE TABLE "applications" (
  "id"             SERIAL                   NOT NULL PRIMARY KEY,
  "country"        VARCHAR(2)               NOT NULL,
  "created"        TIMESTAMP WITH TIME ZONE NOT NULL,
  "is_preliminary" BOOLEAN                  NOT NULL,
  "first_name"     VARCHAR(128)             NOT NULL,
  "last_name"      VARCHAR(128)             NOT NULL,
  "birth_number"   VARCHAR(11)              NULL
);

CREATE TABLE "persons" (
  "id"       UUID                     NOT NULL PRIMARY KEY,
  "created"  TIMESTAMP WITH TIME ZONE NOT NULL,
  "modified" TIMESTAMP WITH TIME ZONE NOT NULL
);

ALTER TABLE "applications" ADD COLUMN "physical_person_id" UUID NULL;
CREATE INDEX "physical_person_id_idx" ON "applications" ("physical_person_id");

ALTER TABLE …

我有一个包含超过 10.000.000 条记录的表，并且我正在创建一个返回大约 4436 条记录的查询。

碰巧它给我的印象是获取最后一条记录的查询成本非常高。

Index Scan using idx_name on task  (cost=0.28..142102.57 rows=3470 width=34) (actual time=14.690..22.894 rows=4436 loops=1)
"  Index Cond: ((situation = ANY ('{0,1,2,3,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20}'::integer[])) AND (deadline < CURRENT_TIMESTAMP))"
Planning Time: 1.335 ms
JIT:
  Functions: 5
  Options: Inlining false, Optimization false, Expressions true, Deforming true
  Timing: Generation 1.654 ms, Inlining 0.000 ms, Optimization 1.214 ms, Emission 13.163 ms, Total 16.030 ms
Execution Time: 24.758 ms

这个成本水平是否可以接受，或者这个指标是否需要改进？

指数：

CREATE INDEX idx_name ON task (situation, deadline, approved)
WHERE
deadline IS NOT …