Re: [GENERAL] Perfomance of IN-clause with many elements and possiblesolutions
| От | Dmitry Lazurkin |
|---|---|
| Тема | Re: [GENERAL] Perfomance of IN-clause with many elements and possiblesolutions |
| Дата | |
| Msg-id | 7fa30f83-2f70-e29d-bd77-d59ac0e0002a@gmail.com обсуждение исходный текст |
| Ответ на | Re: [GENERAL] Perfomance of IN-clause with many elements and possible solutions ("David G. Johnston" <david.g.johnston@gmail.com>) |
| Список | pgsql-general |
On 25.07.2017 01:15, David G. Johnston wrote:
ALTER TABLE ids ALTER COLUMN id SET NOT NULL;
EXPLAIN (ANALYZE, BUFFERS) SELECT count(*) FROM ids WHERE id IN :values_clause;
Aggregate (cost=245006.46..245006.47 rows=1 width=8) (actual time=3824.095..3824.095 rows=1 loops=1)
Buffers: shared hit=44248
-> Hash Join (cost=7.50..235006.42 rows=4000019 width=0) (actual time=1.108..3327.112 rows=3998646 loops=1)
...
Hmmm. No Semi-Join.
PostgreSQL can use Semi-Join for IN too.
And I have one question. I don't understand why IN-VALUES doesn't use Semi-Join? PostgreSQL has Hash Semi-Join... For which task the database has node of this type?Semi-Join is canonically written as:SELECT *FROM tblThe main difference between IN and EXISTS is NULL semantics.David J.
ALTER TABLE ids ALTER COLUMN id SET NOT NULL;
EXPLAIN (ANALYZE, BUFFERS) SELECT count(*) FROM ids WHERE id IN :values_clause;
Aggregate (cost=245006.46..245006.47 rows=1 width=8) (actual time=3824.095..3824.095 rows=1 loops=1)
Buffers: shared hit=44248
-> Hash Join (cost=7.50..235006.42 rows=4000019 width=0) (actual time=1.108..3327.112 rows=3998646 loops=1)
...
Hmmm. No Semi-Join.
PostgreSQL can use Semi-Join for IN too.
В списке pgsql-general по дате отправления: