Re: Fwd: Help with view performance problem - Mailing list pgsql-performance

From Chris Hoover
Subject Re: Fwd: Help with view performance problem
Date
Msg-id 1d219a6f05072810341d67c525@mail.gmail.com
Whole thread Raw
In response to Re: Fwd: Help with view performance problem  (Dan Harris <fbsd@drivefaster.net>)
List pgsql-performance
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?

Thanks,

Chris

On 7/28/05, Dan Harris <fbsd@drivefaster.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.
>
> -Dan
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
>

pgsql-performance by date:

Previous
From: Chris Travers
Date:
Subject: Re: Left joining against two empty tables makes a query
Next
From: Tom Lane
Date:
Subject: Re: Left joining against two empty tables makes a query