Re: How to improve speed of 3 table join &group (HUGE tables)
От | John Major |
---|---|
Тема | Re: How to improve speed of 3 table join &group (HUGE tables) |
Дата | |
Msg-id | 4717BC69.2010809@cbio.mskcc.org обсуждение исходный текст |
Ответ на | Re: How to improve speed of 3 table join &group (HUGE tables) ("Heikki Linnakangas" <heikki@enterprisedb.com>) |
Список | pgsql-performance |
Hi Hekki- When I turn seq_scan off for the new query: explain select sf.library_id, fio.clip_type , count(sf.sequence_id) from sequence_fragment sf, fragment_external_info fio where sf.seq_frag_id = fio.sequence_frag_id and sf.sequence_id IN (SELECT sequence_id from sequence_alignment) group by sf.library_id, fio.clip_type The index is used... but the cost gets worse! it goes from: 11831119 -TO- 53654888 Actually... The new query executes in ~ 15 minutes... which is good enough for me for now. Thanks Nis! john Heikki Linnakangas wrote: > John Major wrote: > >> ~there are indexes on all of the fields being joined (but not on >> library_id or clip_type ). ~Everything has been re-analyzed post index >> creation >> ~I've tried "set enable_seqscan=off" and set (join_table_order or >> something) = 1 >> > > Seqscanning and sorting a table is generally faster than a full scan of > the table using an index scan, unless the heap is roughly in the index > order. You probably need to CLUSTER the tables to use the indexes > effectively. > > Are you sure you have an index on sequence_alignment.sequence_id? The > planner seems to choose a seqscan + sort, even though you've set > enable_seqscan=false. > >
В списке pgsql-performance по дате отправления: