From: | Richard Huxton <dev(at)archonet(dot)com> |
---|---|
To: | Martin Nickel <martin(at)portant(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Sequential scan on FK join |
Date: | 2005-10-17 17:45:38 |
Message-ID: | 4353E342.2060708@archonet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Martin Nickel wrote:
> Subject: Re: Sequential scan on FK join
> From: Martin Nickel <martin(at)portant(dot)com>
> Newsgroups: pgsql.performance
> Date: Wed, 12 Oct 2005 15:53:35 -0500
>
> Richard, here's the EXPLAIN ANALYZE. I see your point re: the 2.7M
> expected vs the 2 actual, but I've run ANALYZE on the lead table and it
> hasn't changed the plan. Suggestions?
>
> Hash Join (cost=62.13..2001702.55 rows=2711552 width=20)
> (actual time=40.659..244709.315 rows=2 125270 loops=1)
^^^
Hmm - is that not just a formatting gap there? Is it not 2,125,270 rows
matching which would suggest PG is getting it more right than wrong.
Try issuing "SET enable_seqscan=false" before running the explain
analyse - that will force the planner to use any indexes it can find and
should show us whether the index would help.
--
Richard Huxton
Archonet Ltd
From | Date | Subject | |
---|---|---|---|
Next Message | Martin Nickel | 2005-10-17 19:56:43 | Re: Sequential scan on FK join |
Previous Message | Oleg Bartunov | 2005-10-17 17:43:13 | Re: tsearch2/GIST performance factors? |