From: | Meetesh Karia <meetesh(dot)karia(at)gmail(dot)com> |
---|---|
To: | Tobias Brox <tobias(at)nordicbet(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Planner incorrectly choosing seq scan over index scan |
Date: | 2005-08-01 23:30:26 |
Message-ID: | fc5b04ca0508011630e745176@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Are you referring to the statistics gathering target for ANALYZE? Based on
your email, I just tried the following and then re-ran the explain analyze
but got the same "incorrect" plan:
alter table candidates617004
alter column sourceId set statistics 1000,
alter column targetId set statistics 1000;
analyze candidates617004;
alter table lte_user
alter column user_id set statistics 1000;
analyze lte_user;
Thanks for your suggestion,
Meetesh
On 8/2/05, Tobias Brox <tobias(at)nordicbet(dot)com> wrote:
>
> [Meetesh Karia - Tue at 12:19:27AM +0200]
> > We're using 8.0.3 and we're seeing a problem where the planner is
> choosing a
> > seq scan and hash join over an index scan. If I set enable_hashjoin to
> off,
> > then I get the plan I'm expecting and the query runs a lot faster. I've
> also
> > tried lowering the random page cost (even to 1) but the planner still
> > chooses to use the hash join.
>
> Have you tried increasing the statistics collection?
>
> --
> Tobias Brox, +47-91700050
> Nordicbet, IT dept
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-08-01 23:51:10 | Re: [PERFORM] COPY FROM performance improvements |
Previous Message | John Arbash Meinel | 2005-08-01 23:16:27 | Re: Planner incorrectly choosing seq scan over index scan |