PostgreSQL查询优化

我有这样的查询，我试图优化它。大约需要1秒钟才能完成。这是性能瓶颈，因为它每秒运行几次。PostgreSQL查询优化

下面是查询：

SELECT "spoleczniak_tablica"."id", "spoleczniak_tablica"."postac_id", 
"spoleczniak_tablica"."hash", "spoleczniak_tablica"."typ", 
"spoleczniak_tablica"."ikona", "spoleczniak_tablica"."opis", 
"spoleczniak_tablica"."cel", "spoleczniak_tablica"."data", "postac_postacie"."id", 
"postac_postacie"."user_id", "postac_postacie"."avatar", "postac_postacie"."ikonka", 
"postac_postacie"."imie", "postac_postacie"."nazwisko", "postac_postacie"."pseudonim", 
"postac_postacie"."plec", "postac_postacie"."wzrost", "postac_postacie"."waga", 
"postac_postacie"."ur_tydz", "postac_postacie"."ur_rok", "postac_postacie"."ur_miasto_id", 
"postac_postacie"."akt_miasto_id", "postac_postacie"."kasa", "postac_postacie"."punkty", 
"postac_postacie"."zmeczenie", "postac_postacie"."zdrowie", "postac_postacie"."kariera" 
FROM "spoleczniak_tablica" INNER JOIN "postac_postacie" ON 
("spoleczniak_tablica"."postac_id" = "postac_postacie"."id") WHERE 
spoleczniak_tablica.postac_id = 1 or spoleczniak_tablica.id in(select wpis_id from 
spoleczniak_oznaczone where etykieta_id in(select tag_id from spoleczniak_subskrypcje where 
postac_id = 1)) or (spoleczniak_tablica.postac_id in(select obserwowany_id from 
spoleczniak_obserwatorium where obserwujacy_id = 1) and hash not in('dyskusja', 'kochanie', 
'szturniecie')) or (spoleczniak_tablica.cel = 1 and spoleczniak_tablica.hash in('dyskusja', 
'kochanie', 'obserwatorium', 'szturchniecie')) or spoleczniak_tablica.hash = 
'administracja-info' or exists(select 1 from spoleczniak_komentarze where kredka_id = 
spoleczniak_tablica.id and postac_id = 1) ORDER BY "spoleczniak_tablica"."id" DESC LIMIT 
21;

这里是EXPLAIN分析一下：

Limit (cost=52.80..184755.97 rows=21 width=282) (actual time=80.637..229.161 rows=21 loops=1) 
    -> Nested Loop (cost=52.80..27584240184.45 rows=3136216 width=282) (actual time=80.637..229.153 rows=21 loops=1) 
     -> Index Scan Backward using spoleczniak_tablica_pkey on spoleczniak_tablica (cost=52.80..27583220399.44 rows=3136216 width=193) (actual time=80.620..228.767 rows=21 loops=1) 
       Filter: ((postac_id = 1) OR (SubPlan 1) OR ((hashed SubPlan 2) AND ((hash)::text <> ALL ('{dyskusja,kochanie,szturniecie}'::text[]))) OR ((cel = 1) AND ((hash)::text = ANY ('{dyskusja,kochanie,obserwatorium,szturchniecie}'::text[]))) OR ((hash)::text = 'administracja-info'::text) OR (alternatives: SubPlan 3 or hashed SubPlan 4)) 
       SubPlan 1 
       -> Materialize (cost=13.22..11858.79 rows=1255820 width=4) (actual time=0.008..0.044 rows=486 loops=1517) 
         -> Nested Loop (cost=13.22..673.69 rows=1255820 width=4) (actual time=11.818..14.028 rows=486 loops=1) 
          -> HashAggregate (cost=5.89..5.90 rows=1 width=4) (actual time=0.051..0.056 rows=7 loops=1) 
            -> Index Scan using spoleczniak_subskrypcje_postac_id on spoleczniak_subskrypcje (cost=0.00..5.88 rows=2 width=4) (actual time=0.022..0.046 rows=7 loops=1) 
             Index Cond: (postac_id = 1) 
          -> Bitmap Heap Scan on spoleczniak_oznaczone (cost=7.33..662.99 rows=384 width=8) (actual time=1.708..1.978 rows=69 loops=7) 
            Recheck Cond: (etykieta_id = spoleczniak_subskrypcje.tag_id) 
            -> Bitmap Index Scan on spoleczniak_oznaczone_etykieta_id (cost=0.00..7.23 rows=384 width=0) (actual time=1.694..1.694 rows=69 loops=7) 
             Index Cond: (etykieta_id = spoleczniak_subskrypcje.tag_id) 
       SubPlan 2 
       -> Index Scan using spoleczniak_obserwatorium_obserwujacy_id on spoleczniak_obserwatorium (cost=0.00..39.53 rows=21 width=4) (actual time=0.041..0.192 rows=26 loops=1) 
         Index Cond: (obserwujacy_id = 1) 
       SubPlan 3 
       -> Bitmap Heap Scan on spoleczniak_komentarze (cost=18.63..20.64 rows=1 width=0) (never executed) 
         Recheck Cond: ((kredka_id = spoleczniak_tablica.id) AND (postac_id = 1)) 
         -> BitmapAnd (cost=18.63..18.63 rows=1 width=0) (never executed) 
          -> Bitmap Index Scan on spoleczniak_komentarze_kredka_id (cost=0.00..2.98 rows=24 width=0) (never executed) 
            Index Cond: (kredka_id = spoleczniak_tablica.id) 
          -> Bitmap Index Scan on spoleczniak_komentarze_postac_id (cost=0.00..15.40 rows=885 width=0) (never executed) 
            Index Cond: (postac_id = 1) 
       SubPlan 4 
       -> Index Scan using spoleczniak_komentarze_postac_id on spoleczniak_komentarze (cost=0.00..1616.70 rows=885 width=4) (actual time=0.044..54.812 rows=3607 loops=1) 
         Index Cond: (postac_id = 1) 
     -> Index Scan using postac_postacie_pkey on postac_postacie (cost=0.00..0.31 rows=1 width=89) (actual time=0.012..0.014 rows=1 loops=21) 
       Index Cond: (id = spoleczniak_tablica.postac_id)

如果我删除ORDER BY，查询需要只需2-3毫秒。有什么建议么？

来源

2011-08-25 ThomK

您正在排序3082289行。毫不奇怪，它需要非常长的时间。使用临时表来减少选定的数据量可能是一个好主意。您可以在没有订单的情况下发布'ANALYZE'输出吗？ – J0HN

我看不到一种排序。在我看来，它正在使用索引并向后计数，直到它有21个被接受的记录。我们确实需要'EXPLAIN ANALYSE'来看看过滤器的选择性。也就是说，我想我会尝试重写包含'etykieta_id'的filter子句来使用联接而不是嵌套子查询。 –

我用EXPLAIN ANALYZE更新了问题。 – ThomK

真正需要在这里完成的第一件事是重新设计此查询以使其更具可读性。这意味着将子查询移动到连接中。

从阅读解释输出结果来看，第二件事是计划者假设的行数比实际得到的多得多。这导致它可能不必要地实现。这里要做的大事可能是增加相关表的统计目标并重新运行分析数据库。

这就是说，为什么它知道有不超过21的时候计划这么多行？这看起来很像我的计划者限制，升级到更新的PostgreSQL主要版本可能会解决问题。

来源

2013-03-21 11:58:52

PostgreSQL查询优化

回答

相关问题