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

From Nis Jørgensen
Subject Re: How to improve speed of 3 table join &group (HUGE tables)
Date
Msg-id ffkl74$tik$1@ger.gmane.org
Whole thread Raw
In response to Re: How to improve speed of 3 table join &group (HUGE tables)  (John Major <major@cbio.mskcc.org>)
List pgsql-performance
John Major skrev:
> Hello Nis-
>
> I did reset the defaults before running the explain.

This line from your original post:

->  Seq Scan on sequence_alignment sa  (cost=100000000.00..110379294.60
rows=467042560 width=4)

Is an indication that you didn't (AFAIK enable_seqscan=off works by
setting the cost of starting a seqscan to 100000000).

> Candidate keys.
>  fragment_external_info.seq_frag_id (FK to sequence_fragment.seq_frag_id)
>  sequence_alignment.sequence_id (FK to sequence_fragment.sequence_id).

Those are not candidate keys. A candidate key is "something which could
have been chosen as the primary key". Anyway, I think I understand your
table layout now. It might have been quicker if you just posted the
definition of your tables. This could also have shown us that the
correct indexes are in place, rather than taking your word for it.

You are absolutely certain that both sides of all FK relationships are
indexed?

> After  making the 2 changes, the cost dropped dramatically... but is still very high.
> Original Explain cost:
> cost=1308049564..1345206293 rows=54 width=16
>
> New Explain cost:
> cost=11831119..11831120 rows=54 width=16

Please post the full output if you want more help. And preferably use
EXPLAIN ANALYZE, now that it runs in finite time.


Nis

pgsql-performance by date:

Previous
From: Pavel Velikhov
Date:
Subject: Re: need help with a query
Next
From: Adrian Demaestri
Date:
Subject: Re: Seqscan