I'm alreading running at 1.5. It looks like if I drop the
random_page_cost t0 1.39, it starts using the indexes. Are there any
unseen issues with dropping the random_page_cost this low?
On 7/28/05, Dan Harris <fbsd(at)drivefaster(dot)net> wrote:
> On Jul 28, 2005, at 8:38 AM, Chris Hoover wrote:
> > I did some more testing, and ran the explain analyze on the problem.
> > In my session I did a set enable_hashjoin = false and then ran the
> > analyze. This caused it to use the indexes as I have been expecting
> > it to do.
> > Now, how can I get it to use the indexes w/o manipulating the
> > environment? What make postgresql want to sequentially scan and use a
> > hash join?
> > thanks,
> > Chris
> > explain analyze with set_hashjoin=false;
> > prob_db=#explain analyze select * from clm_com;
> I had something similar to this happen recently. The planner was
> choosing a merge join and seq scan because my 'random_page_cost' was
> set too high. I had it at 3 , and ended up settling at 1.8 to get it
> to correctly use my indices. Once that change was in place, the
> planner did the 'right' thing for me.
> Not sure if this will help you, but it sounds similar.
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
In response to
pgsql-performance by date
|Next:||From: Tom Lane||Date: 2005-07-28 18:13:51|
|Subject: Re: Left joining against two empty tables makes a query |
|Previous:||From: Steven Rosenstein||Date: 2005-07-28 17:00:05|
|Subject: Unable to explain DB error|
pgsql-admin by date
|Next:||From: Gregory Zelesnik||Date: 2005-07-28 18:53:39|
|Subject: Re: libpq.so.3 compatability problem still there for 8.0.3 installs|
|Previous:||From: Dan Harris||Date: 2005-07-28 16:14:32|
|Subject: Re: Fwd: Help with view performance problem|