我有这样的查询:
SELECT t0.id
FROM platform_conversations t0
LEFT OUTER JOIN contacts t1 ON t1.id = t0.contact_id
WHERE t0.user_id = 5340
AND (
t0.participant ILIKE '%baa%' -- (1)
OR t1.first_name ILIKE '%baa%' -- (2)
)
LIMIT 50;
和
CREATE INDEX ix_conversations_participant
ON platform_conversations USING GIN (participant gin_trgm_ops);
CREATE INDEX ix_trgm_contacts_search
ON contacts USING GIN (first_name gin_trgm_ops);
并且无法弄清楚为什么索引不与OR
条件一起使用。如果我只使用 (1),或只使用 (2),或AND
改为使用,它们都会被使用。
这是计划:
仅供 (1)
Limit (cost=12.43..203.68 rows=50 width=37) (actual time=0.037..0.037 rows=0 loops=1)
-> Bitmap Heap Scan on platform_conversations t0 (cost=12.43..222.80 rows=55 width=37) (actual time=0.030..0.030 rows=0 loops=1)
Recheck Cond: ((participant)::text ~~* '%baa%'::text)
Filter: (user_id = 5340)
-> Bitmap Index Scan on ix_conversations_participant (cost=0.00..12.42 rows=55 width=0) (actual time=0.012..0.012 rows=0 loops=1)
Index Cond: ((participant)::text ~~* '%baa%'::text)
Planning time: 0.397 ms
Execution time: 0.092 ms
仅供 (2)
Limit (cost=16.71..446.06 rows=50 width=37) (actual time=0.034..0.034 rows=0 loops=1)
-> Nested Loop (cost=16.71..471.82 rows=53 width=37) (actual time=0.028..0.028 rows=0 loops=1)
-> Bitmap Heap Scan on contacts t1 (cost=16.29..158.99 rows=37 width=37) (actual time=0.022..0.022 rows=0 loops=1)
Recheck Cond: ((first_name)::text ~~* '%baa%'::text)
-> Bitmap Index Scan on ix_trgm_contacts_search (cost=0.00..16.28 rows=37 width=0) (actual time=0.016..0.016 rows=0 loops=1)
Index Cond: ((first_name)::text ~~* '%baa%'::text)
-> Index Scan using ix_platform_conversations_contact_id on platform_conversations t0 (cost=0.42..8.45 rows=1 width=74) (never executed)
Index Cond: ((contact_id)::text = (t1.id)::text)
Filter: (user_id = 5340)
Planning time: 0.840 ms
Execution time: 0.121 ms
慢一个(用或):
Limit (cost=25771.43..47419.63 rows=50 width=37) (actual time=6652.292..6652.292 rows=0 loops=1)
-> Hash Left Join (cost=25771.43..72531.55 rows=108 width=37) (actual time=6652.282..6652.282 rows=0 loops=1)
Hash Cond: ((t0.contact_id)::text = (t1.id)::text)
Filter: (((t0.participant)::text ~~* '%baa%'::text) OR ((t1.first_name)::text ~~* '%baa%'::text))
Rows Removed by Filter: 553477
-> Seq Scan on platform_conversations t0 (cost=0.00..20627.29 rows=553512 width=87) (actual time=0.045..1741.899 rows=553477 loops=1)
Filter: (user_id = 5340)
Rows Removed by Filter: 386
-> Hash (cost=17578.19..17578.19 rows=384819 width=46) (actual time=2372.508..2372.508 rows=384819 loops=1)
Buckets: 65536 Batches: 16 Memory Usage: 2359kB
-> Seq Scan on contacts t1 (cost=0.00..17578.19 rows=384819 width=46) (actual time=0.014..1168.218 rows=384819 loops=1)
Planning time: 0.741 ms
Execution time: 6652.333 ms
它不能只对 t1、t2 进行位图索引扫描,然后对它们进行位图 OR 吗?为什么 OR 这样的问题?
Postgres 9.6(无法创建标签,没有足够的代表)
问题是:“你想在加入之后过滤数据吗?还是在加入之前你想要过滤数据? ”
因为使用时缺少数据
OR
。这就是为什么 PG 需要sequence scan
在这些表上做一个。你的情况是
t1.id = t2.contract_id, (1) or (2)
。在你的情况下,假设 PG 将使用
bitmap
索引,即t1
使用(1)
和t2
使用(2)
。在这里,您可以查看是否(1)
为假 (!),然后检查(2)
. 问题是如果为真,将缺少(2)
列的数据。(1)
(!)
如果 PG 真的使用bitmap
索引,这种情况从来没有发生过(因为 (1) 总是 true)。在这里,我关于 AFTER-BEFORE 加入的简单示例(Postgres 9.6):
来自Kadek的更新
太好了,union是个不错的选择。根据您的查询,您可以在表
first_name
上创建一个新列platform_conversations
,然后为两列first_name
和创建一个索引participant
。当然,您应该在写入和读取流程之间取得平衡。