Re: How to improve speed of 3 table join &group (HUGE tables) - Mailing list pgsql-performance

From John Major
Subject Re: How to improve speed of 3 table join &group (HUGE tables)
Date
Msg-id 4717BC69.2010809@cbio.mskcc.org
Whole thread Raw
In response to Re: How to improve speed of 3 table join &group (HUGE tables)  ("Heikki Linnakangas" <heikki@enterprisedb.com>)
List 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 by date:

Previous
From: John Major
Date:
Subject: Re: How to improve speed of 3 table join &group (HUGE tables)
Next
From: Chris Kratz
Date:
Subject: Re: Incorrect estimates on columns