相关疑难解决方法(0)

使用PostgreSQL 8.4.9,我对查询的PostgreSQL性能有一个奇怪的问题.此查询正在选择3D卷中的一组点,使用a LEFT OUTER JOIN添加相关ID列,其中存在相关ID.x范围的微小变化可能导致PostgreSQL选择不同的查询计划,执行时间从0.01秒到50秒.这是有问题的查询:

SELECT treenode.id AS id,
       treenode.parent_id AS parentid,
       (treenode.location).x AS x,
       (treenode.location).y AS y,
       (treenode.location).z AS z,
       treenode.confidence AS confidence,
       treenode.user_id AS user_id,
       treenode.radius AS radius,
       ((treenode.location).z - 50) AS z_diff,
       treenode_class_instance.class_instance_id AS skeleton_id
  FROM treenode LEFT OUTER JOIN
         (treenode_class_instance INNER JOIN
          class_instance ON treenode_class_instance.class_instance_id
                                                  = class_instance.id
                            AND class_instance.class_id = 7828307)
       ON (treenode_class_instance.treenode_id = treenode.id
           AND treenode_class_instance.relation_id = 7828321)
  WHERE treenode.project_id = 4
    AND (treenode.location).x >= 8000
    AND (treenode.location).x <= (8000 + 4736) …

我有点困惑，需要一些建议。我用PostgreSQL 11数据库。我有这么简单的sql语句：

SELECT DISTINCT "CITY", "AREA", "REGION"
    FROM youtube
WHERE
    "CITY" IS NOT NULL
AND
    "AREA" IS NOT NULL
AND
    "REGION" IS NOT NULL

youtube我在 sql 语句中使用的表有 2500 万条记录。我认为这就是为什么查询需要 15-17 秒才能完成。对于我使用该查询的 Web 项目，它太长了。我正在尝试加快请求。

我为 youtube 表创建了这样的索引：

CREATE INDEX youtube_location_idx ON public.youtube USING btree ("CITY", "AREA", "REGION");

在这一步之后，我再次运行查询，但需要相同的时间才能完成。似乎查询不使用索引。我如何知道查询中是否使用了任何索引？

解释分析返回：

位图扫描的作者描述了位图堆扫描和索引扫描之间的区别：

一个普通的indexscan一次从索引中获取一个元组指针，然后立即访问表中的该元组。位图扫描一次性从索引中获取所有元组指针，使用内存中的“位图”数据结构对其进行排序，然后以物理元组位置顺序访问表元组。位图扫描提高了表的引用局部性，但要花更多的簿记开销来管理“位图”数据结构---并且不再按索引顺序检索数据，这对您来说无关紧要查询，但是如果您说ORDER BY会很重要。

问题：

1. 当索引已排序时，为什么又对获取的元组指针进行排序？

2. 它如何与位图排序？我知道位图是什么，但是我不知道如何将其用于排序。

3. 为何要获取中等比例的表，为什么它比索引扫描更快？相反，它似乎为该过程增加了很多计算。

在 PostgreSQL 中，我的表上的日期字段有一个索引tickets。当我将字段与 进行比较时now()，查询非常有效：

# explain analyze select count(1) as count from tickets where updated_at > now();
                                                             QUERY PLAN                                                                  
---------------------------------------------------------------------------------------------------------------------------------------------
Aggregate  (cost=90.64..90.66 rows=1 width=0) (actual time=33.238..33.238 rows=1 loops=1)
   ->  Index Scan using tickets_updated_at_idx on tickets  (cost=0.01..90.27 rows=74 width=0) (actual time=0.016..29.318 rows=40250 loops=1)
         Index Cond: (updated_at > now())
Total runtime: 33.271 ms

now()如果我尝试将其与负间隔进行比较，它会走下坡路并使用位图堆扫描。

# explain analyze select count(1) as count from tickets where updated_at > (now() - '24 hours'::interval);
                                                                  QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------------------
Aggregate  (cost=180450.15..180450.17 rows=1 width=0) …

PostgreSQL 9.5.0

我有一个表，称为message_attachments它有1931964行。

我在该表中搜索一个键，那就是message_id.

我还总是包含deleted_atis NULL 语句（例如软删除）。

创建了一个索引：

CREATE INDEX message_attachments_message_id_idx 
   ON message_attachments (message_id) 
WHERE deleted_at IS NULL;

所以它应该直接匹配这个查询：

EXPLAIN ANALYZE 
select * 
from "message_attachments" 
where "deleted_at" is null 
  and "message_id" = 33998052;

但生成的查询计划如下所示：

Seq Scan on message_attachments  (cost=0.00..69239.91 rows=4 width=149) (actual time=1667.850..1667.850 rows=0 loops=1)
   Filter: ((deleted_at IS NULL) AND (message_id = 33998052))
   Rows Removed by Filter: 1931896
 Planning time: 0.114 ms
 Execution time: 1667.885 ms

我在整个数据库中使用此类索引，但不知何故，它似​​乎不喜欢该特定表上的索引。

关于基数，最多有 5 列具有相同的值。

还在该表上运行了 ANALYZE …