Why isn't PG using an index-only scan?
От | Jean-Christophe BOGGIO |
---|---|
Тема | Why isn't PG using an index-only scan? |
Дата | |
Msg-id | 8f25c08c-acb2-47ca-b8c1-6664fc31a361@thefreecat.org обсуждение исходный текст |
Ответы |
Re: Why isn't PG using an index-only scan?
|
Список | pgsql-performance |
Hello,
I have this very simple query:
INSERT INTO copyrightad (idoeu, idad, role, mechowned, perfowned, iscontrolled)
SELECT o.idoeu, c.idad, LEFT(sipa_capacity1,3), sipa_mech_owned, sipa_perf_owned, sipa_controlled='Y'
FROM imaestro.msipfl ip
JOIN oeu o ON o.imworkid=ip.sipa_song_code
JOIN ad c ON c.imcompid=ip.sipa_ip_code
WHERE ip.sipa_comp_or_publ='C';
And here are the number of elements in each table:
imaestro.msipfl: 1550019
oeu: 1587533
ad: 304986
The explain plan is saying this:
QUERY PLAN
----------------------------------------------------------------------------------------------------------
Insert on copyrightad (cost=613790.59..4448045.97 rows=0 width=0)
-> Merge Join (cost=613790.59..4448045.97 rows=84972138 width=328)
Merge Cond: (((c.imcompid)::numeric) = ip.sipa_ip_code)
-> Sort (cost=35712.97..36475.44 rows=304986 width=8)
Sort Key: ((c.imcompid)::numeric)
-> Index Only Scan using ix_ad_imcompid on ad c (cost=0.42..7931.21 rows=304986 width=8)
-> Materialize (cost=578077.61..594521.17 rows=3288712 width=23)
-> Sort (cost=578077.61..586299.39 rows=3288712 width=23)
Sort Key: ip.sipa_ip_code
-> Hash Join (cost=56043.04..154644.48 rows=3288712 width=23)
Hash Cond: ((o.imworkid)::numeric = ip.sipa_song_code)
-> Seq Scan on oeu o (cost=0.00..41901.33 rows=1587533 width=8)
-> Hash (cost=48542.24..48542.24 rows=600064 width=25)
-> Seq Scan on msipfl ip (cost=0.00..48542.24 rows=600064 width=25)
Filter: ((sipa_comp_or_publ)::text = 'C'::text)
Table ad has this index:
"ix_ad_imcompid" btree (imcompid, idad)
Table oeu has this one:
"ix_oeu_imcompid" btree (imworkid, idoeu)
idad and idoeu are both primary keys of, respectively, ad and oeu.
The resultset should be 591615 rows because:
select sipa_comp_or_publ, count(*) from imaestro.msipfl group by 1;
sipa_comp_or_publ | count
-------------------+--------
C | 591615
P | 958404
Is it normal that PG is doing a seq scan on table oeu but an index-only scan on ad? I had to stop the query after 5 hours, how can I make this faster? Of course I ran VACUUM ANALYZE.
These are the memory settings I have, but I have plenty of unused RAM. Should I bump something up?
shared_buffers = 16GB # min 128kB
#huge_pages = try # on, off, or try
#huge_page_size = 0 # zero for system default
#temp_buffers = 8MB # min 800kB
#max_prepared_transactions = 0 # zero disables the feature
work_mem = 128MB # min 64kB
$ free -h
total used free shared buff/cache available
Mem: 125Gi 18Gi 3.1Gi 15Gi 121Gi 106Gi
Swap: 4.0Gi 2.0Gi 2.0Gi
Thanks for your help,
JC
В списке pgsql-performance по дате отправления: