Re: Fwd: Help with view performance problem
От | Chris Hoover |
---|---|
Тема | Re: Fwd: Help with view performance problem |
Дата | |
Msg-id | 1d219a6f05072810341d67c525@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Fwd: Help with view performance problem (Dan Harris <fbsd@drivefaster.net>) |
Список | 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 по дате отправления: