Postgresql中的慢OR语句

传统酿酒

我目前有一个原因OR由句子引起的PostgreSQL查询缓慢。因此，显然没有索引。到目前为止，此查询的重写失败。
查询：
EXPLAIN ANALYZE SELECT a0_.id AS id0FROM advert a0_    INNER JOIN advertcategory a1_             ON a0_.advert_category_id = a1_.idWHERE  a0_.advert_category_id IN    OR a1_.parent_id IN ( 1136 )ORDER  BY a0_.created_date DESCLIMIT  15；                                                                                                                         QUERY PLAN                                                                               ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Limit  (cost=0.00..27542.49 rows=15 width=12) (actual time=1.658..50.809 rows=15 loops=1) ->  Nested Loop  (cost=0.00..1691109.07 rows=921 width=12) (actual time=1.657..50.790 rows=15 loops=1)          ->  Index Scan Backward using advert_created_date_idx on advert a0_  (cost=0.00..670300.17 rows=353804 width=16) (actual time=0.013..16.449 rows=12405 loops=1)          ->  Index Scan using advertcategory_pkey on advertcategory a1_  (cost=0.00..2.88 rows=1 width=8) (actual time=0.002..0.002 rows=0 loops=12405)       Index Cond: (id = a0_.advert_category_id)             Filter: ((a0_.advert_category_id = 1136) OR (parent_id =       Rows Removed by Filter: 1 Total runtime: 50.860 ms原因慢： Filter: ((a0_.advert_category_id = 1136) OR (parent_id = 1136))
我尝试使用INNER JOIN代替WHERE语句：
EXPLAIN ANALYZE  SELECT a0_.id AS id0FROM advert a0_    INNER JOIN advertcategory a1_             ON a0_.advert_category_id = a1_.id                AND ( a0_.advert_category_id IN                   OR a1_.parent_id IN ( 1136 ) )ORDER  BY a0_.created_date DESCLIMIT  15；                                                                                                                            QUERY PLAN                                                                               -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Limit  (cost=0.00..27542.49 rows=15 width=12) (actual time=4.667..139.955 rows=15 loops=1) ->  Nested Loop  (cost=0.00..1691109.07 rows=921 width=12) (actual time=4.666..139.932 rows=15 loops=1)          ->  Index Scan Backward using advert_created_date_idx on advert a0_  (cost=0.00..670300.17 rows=353804 width=16) (actual time=0.019..100.765 rows=12405 loops=1)          ->  Index Scan using advertcategory_pkey on advertcategory a1_  (cost=0.00..2.88 rows=1 width=8) (actual time=0.002..0.002 rows=0 loops=12405)       Index Cond: (id = a0_.advert_category_id)             Filter: ((a0_.advert_category_id = 1136) OR (parent_id =       Rows Removed by Filter: 1 Total runtime: 140.048 ms当我删除OR在条件之一时，查询速度加快。因此，我创建了一个UNION查看结果。非常快！但我不认为这是一个解决方案：
EXPLAIN ANALYZE  (SELECT a0_.id AS id0 FROM advert a0_       INNER JOIN advertcategory a1_             ON a0_.advert_category_id = a1_.id WHERE  a0_.advert_category_id IN ( 1136 ) ORDER  BY a0_.created_date DESC LIMIT  15)UNION(SELECT a0_.id AS id0 FROM advert a0_       INNER JOIN advertcategory a1_             ON a0_.advert_category_id = a1_.id WHERE  a1_.parent_id IN ( 1136 ) ORDER  BY a0_.created_date DESC LIMIT 15)；                                                                                                             QUERY PLAN                                                                                  --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- HashAggregate  (cost=4125.70..4126.00 rows=30 width=12) (actual time=7.945..7.951 rows=15 loops=1) ->  Append  (cost=1120.82..4125.63 rows=30 width=12) (actual time=6.811..7.929 rows=15 loops=1)          ->  Subquery Scan on "*SELECT* 1"  (cost=1120.82..1121.01 rows=15 width=12) (actual time=6.810..6.840 rows=15 loops=1)                ->  Limit  (cost=1120.82..1120.86 rows=15 width=12) (actual time=6.809..6.825 rows=15 loops=1)                      ->  Sort  (cost=1120.82..1121.56 rows=295 width=12) (actual time=6.807..6.813 rows=15 loops=1)                            Sort Key: a0_.created_date                         Sort Method: top-N heapsort  Memory: 25kB                         ->  Nested Loop  (cost=10.59..1113.59 rows=295 width=12) (actual time=1.151..6.639 rows=220 loops=1)                                  ->  Index Only Scan using advertcategory_pkey on advertcategory a1_  (cost=0.00..8.27 rows=1 width=4) (actual time=1.030..1.033 rows=1 loops=1)                                        Index Cond: (id = 1136)                                     Heap Fetches:                                                             ->  Bitmap Heap Scan on advert a0_  (cost=10.59..1102.37 rows=295 width=16) (actual time=0.099..5.287 rows=220 loops=1)                                                                                                                                                             Recheck Cond: (advert_category_id =1136)                               ->  Bitmap Index Scan on idx_54f1f40bd4436821  (cost=0.00..10.51 rows=295 width=0) (actual time=0.073..0.073 rows=220 loops=1)                                                                                                                                                                   Index Cond: (advert_category_id =    ->  Subquery Scan on "*SELECT* 2"  (cost=3004.43..3004.62 rows=15 width=12) (actual time=1.072..1.072 rows=0 loops=1)                ->  Limit  (cost=3004.43..3004.47 rows=15 width=12) (actual time=1.071..1.071 rows=0 loops=1)                      ->  Sort  (cost=3004.43..3005.99 rows=626 width=12) (actual time=1.069..1.069 rows=0 loops=1)                            Sort Key: a0_.created_date                         Sort Method: quicksort  Memory: 25kB                         ->  Nested Loop  (cost=22.91..2989.07 rows=626 width=12) (actual time=1.056..1.056 rows=0 loops=1)                                  ->  Index Scan using idx_d84ab8ea727aca70 on advertcategory a1_  (cost=0.00..8.27 rows=1 width=4) (actual time=1.054..1.054 rows=0 loops=1)                                                                                                                                                             Index Cond: (parent_id =                            ->  Bitmap Heap Scan on advert a0_  (cost=22.91..2972.27 rows=853 width=16) (never executed)                                     Recheck Cond: (advert_category_id = a1_.id)                                     ->  Bitmap Index Scan on idx_54f1f40bd4436821  (cost=0.00..22.70 rows=853 width=0) (never executed)                                           Index Cond: (advert_category_id = a1_.id) Total runtime: 8.940 ms(28 rows)尝试反转IN语句：
EXPLAIN ANALYZE  SELECT a0_.id AS id0FROM advert a0_    INNER JOIN advertcategory a1_             ON a0_.advert_category_id = a1_.idWHERE  1136 IN ( a0_.advert_category_id,a1_.parent_id )ORDER  BY a0_.created_date DESCLIMIT  15；                                                                                                                            QUERY PLAN                                                                               ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Limit  (cost=0.00..27542.49 rows=15 width=12) (actual time=1.848..62.461 rows=15 loops=1) ->  Nested Loop  (cost=0.00..1691109.07 rows=921 width=12) (actual time=1.847..62.441 rows=15 loops=1)          ->  Index Scan Backward using advert_created_date_idx on advert a0_  (cost=0.00..670300.17 rows=353804 width=16) (actual time=0.028..27.316 rows=12405 loops=1)          ->  Index Scan using advertcategory_pkey on advertcategory a1_  (cost=0.00..2.88 rows=1 width=8) (actual time=0.002..0.002 rows=0 loops=12405)       Index Cond: (id = a0_.advert_category_id)             Filter: ((1136 = a0_.advert_category_id) OR (1136 = parent_id))             Rows Removed by Filter: 1 Total runtime: 62.506 ms(8 rows)使用EXISTS尝试：
EXPLAIN ANALYZE  SELECT a0_.id AS id0FROM advert a0_    INNER JOIN advertcategory a1_             ON a0_.advert_category_id = a1_.idWHERE  EXISTS(SELECT test.id             FROM advert test                   INNER JOIN advertcategory test_cat                            ON test_cat.id = test.advert_category_id             WHERE  test.id = a0_.id                   AND ( test.advert_category_id IN (1136)                      OR test_cat.parent_id IN ( 1136 )ORDER  BY a0_.created_date DESCLIMIT  15；                                                                                                                      QUERY PLAN                                                                         --------------------------------------------------------------------------------------------------------------------------------------------------------------- Limit  (cost=45538.18..45538.22 rows=15 width=12) (actual time=524.654..524.673 rows=15 loops=1) ->  Sort  (cost=45538.18..45540.48 rows=921 width=12) (actual time=524.651..524.658 rows=15 loops=1)          Sort Key: a0_.created_date       Sort Method: top-N heapsort  Memory: 25kB       ->  Hash Join  (cost=39803.59..45515.58 rows=921 width=12) (actual time=497.362..524.436 rows=220 loops=1)                Hash Cond: (a0_.advert_category_id = a1_.id)             ->  Nested Loop  (cost=39786.88..45486.21 rows=921 width=16) (actual time=496.748..523.501 rows=220 loops=1)                      ->  HashAggregate  (cost=39786.88..39796.09 rows=921 width=4) (actual time=496.705..496.872 rows=220 loops=1)                            ->  Hash Join  (cost=16.71..39784.58 rows=921 width=4) (actual time=1.210..496.294 rows=220 loops=1)                                  Hash Cond: (test.advert_category_id = test_cat.id)                               Join Filter: ((test.advert_category_id = 1136) OR (test_cat.parent_id =1136)                               Rows Removed by Join Filter:3553584                                                                                                                                                                                                                                                                                                                                                                                                                               ->  Seq Scan on advert test  (cost=0.00..33134.04 rows=353804 width=8) (actual time=0.002..177.953 rows=353804 loops=1)                                                                               ->  Hash  (cost=9.65..9.65 rows=565 width=8) (actual time=0.622..0.622 rows=565 loops=1)                                                                                     Buckets: 1024  Batches: 1  Memory Usage: 22kB                                     ->  Seq Scan on advertcategory test_cat  (cost=0.00..9.65 rows=565 width=8) (actual time=0.005..0.327 rows=565 loops=1)                ->  Index Scan using advert_pkey on advert a0_  (cost=0.00..6.17 rows=1 width=16) (actual time=0.117..0.118 rows=1 loops=220)             Index Cond: (id = test.id)             ->  Hash  (cost=9.65..9.65 rows=565 width=4) (actual time=0.604..0.604 rows=565 loops=1)                Buckets: 1024  Batches: 1  Memory Usage: 20kB                   ->  Seq Scan on advertcategory a1_  (cost=0.00..9.65 rows=565 width=4) (actual time=0.010..0.285 rows=565 loops=1) Total runtime: 524.797 ms广告表(向下细分):
353804 rows                                                                Table "public.advert"          Column          |             Type             |                   Modifiers                   | Storage  | Stats target | Description ----------------------------- -------------------------------- ----------------------------------------------------- ---------- -------------- ------------- id                         | integer                      | not null default nextval('advert_id_seq'::regclass) | plain |             |  advert_category_id       | integer                      | not null                                           | plain |             | Indexes: "idx_54f1f40bd4436821" btree (advert_category_id) "advert_created_date_idx" btree (created_date)Foreign-key constraints: "fk_54f1f40bd4436821" FOREIGN KEY (advert_category_id) REFERENCES advertcategory(id) ON DELETE RESTRICTHas OIDs: no类别表(向下细分):
btree (id) "idx_d84ab8ea727aca70" btree (parent_id)Foreign-key constraints: "fk_d84ab8ea727aca70" FOREIGN KEY (parent_id) REFERENCES advertcategory(id) ON DELETE RESTRICTbtree (id) "idx_d84ab8ea727aca70" btree (parent_id)Foreign-key constraints: "fk_d84ab8ea727aca70" FOREIGN KEY (parent_id) REFERENCES advertcategory(id) ON DELETE RESTRICT服务器配置简短：
                                                                                                                                                                                                         version                                                 -------------------------------------------------------------------------------------------------------------- PostgreSQL 9.2.4 on x86_64-unknown-linux-gnu,compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-3),64-bit          name          |  current_setting |       source       ---------------------------- -------------------- ---------------------- shared_buffers          | 1800MB          | configuration file work_mem                | 4MB             | configuration file如你所见，没有合适的解决方案可以提高速度。UNION可拆分解决方案OR句子可以提高性能。但是我不能用它，因为这个查询是通过我的ORM使用框架和许多其他过滤器选项。此外，如果我能做到这一点，为什么优化器不这样做呢？这似乎是一个非常简单的优化。
有什么提示吗？我将非常感谢这个小问题的解决方案！

解决方案:
                                                            另外，如果我能做到这一点，为什么优化器不这样做呢？-因为在各种情况下，这并不一定是有效的（因为子查询中的收集）或有趣的（因为更好的索引）。
在Gordon答案给出了您可能获得的最佳查询计划，并使用它unionall而不是union避免排序(我认为一个类别永远不是它自己的父类别，从而消除了重复的可能性)。
否则，请注意您的查询可以重写：
SELECT a0_.id AS id0FROM advert a0_    INNER JOIN advertcategory a1_             ON a0_.advert_category_id = a1_.idWHERE  a1_.id IN    OR a1_.parent_id IN ( 1136 )ORDER  BY a0_.created_date DESCLIMIT  15;换句话说，您正在根据一个表中的条件进行过滤，并根据另一个表中的排名/限制进行过滤。你写它的方式使你无法使用好的索引，因为计划者无法识别来自同一个表的过滤条件，因此它将嵌套在您目前正在使用的过滤器中created_date以上。请注意，这不是一个坏计划。假如1136不是很严格的标准，是正确的选择。
如果你已经索引了第二表，你可能最终会得到一个位图堆扫描的类别，这是不够的选择性。advertcategory(id)(如果是主键，你已经拥有了)和advertcategory (parent_id)(你可能还没有)。但是，不要指望太多-
据我所知，PG不会收集相关的列信息。
另一种可能性是直接在广告中维护一个具有汇总类别的数组(使用触发器)，并使用它GIST索引：
SELECT a0_.id AS id0FROM advert a0_WHERE  ARRAY[1136,1137] && a0_.category_ids -- 1136 OR 1137; use 从技术上讲，它是多余的，但它可以优化此类查询（例如，嵌套树上的过滤器会产生复杂的连接条件）…当PG当你决定使用它时，你最终会提前做适用的广告n排名PG版本中，&&由于缺乏统计信息，选择性是任意的；我隐约记得读过一本变更日志，其中9.1、9.2或9.3改进事物可能类似于使用tsvector对于通用数组类型使用的代码，请确保使用最新的内容统计信息收集器PG版本，确保不使用gin/gist索引的操作符重写查询。

Postgresql中的慢OR语句

传统酿酒 LV1