От: Dan Langille
Тема: Re: seq scan woes
Дата: ,
Msg-id: 40C49FAC.11805.49212810@localhost
(см: обсуждение, исходный текст)
Ответ на: Re: seq scan woes  ("Dan Langille")
Список: pgsql-performance

Скрыть дерево обсуждения

seq scan woes  ("Dan Langille", )
 Re: seq scan woes  ("Dan Langille", )
  Re: seq scan woes  ("Dan Langille", )
  Re: seq scan woes  ("Dan Langille", )
   Re: seq scan woes  ("Dan Langille", )
  Re: seq scan woes  (Rod Taylor, )
 Re: seq scan woes  (Rod Taylor, )

On 7 Jun 2004 at 16:38, Rod Taylor wrote:

> On Mon, 2004-06-07 at 16:12, Dan Langille wrote:
> > On 7 Jun 2004 at 16:00, Rod Taylor wrote:
> >
> > > On Mon, 2004-06-07 at 15:45, Dan Langille wrote:
> > > > A production system has had a query recently degrade in performance.
> > > > What once took < 1s now takes over 1s.  I have tracked down the
> > > > problem to a working example.
> > >
> > > What changes have you made to postgresql.conf?
> >
> > Nothing recently (ie. past few months). Nothing at all really.
> > Perhaps I need to start tuning that.
> >
> > > Could you send explain analyse again with SEQ_SCAN enabled but with
> > > nested loops disabled?
> >
> > See http://rafb.net/paste/results/zpJEvb28.html
>
> This doesn't appear to be the same query as we were shown earlier.

My apologies. I should try to cook dinner and paste at the same time.
 ;)

http://rafb.net/paste/results/rVr3To35.html is the right query.

> > > Off the cuff? I might hazard a guess that effective_cache is too low or
> > > random_page_cost is a touch too high. Probably the former.
> >
> > I grep'd postgresql.conf:
> >
> > #effective_cache_size = 1000    # typically 8KB each
> > #random_page_cost = 4           # units are one sequential page fetch cost
>
> This would be the issue. You haven't told PostgreSQL anything about your
> hardware. The defaults are somewhat modest.
>
> http://www.postgresql.org/docs/7.4/static/runtime-config.html
>
> Skim through the run-time configuration parameters that can be set in
> postgresql.conf.
>
> Pay particular attention to:
>       * shared_buffers (you may be best with 2000 or 4000)
>       * effective_cache_size (set to 50% of ram size if dedicated db
>         machine)
>       * random_page_cost (good disks will bring this down to a 2 from a
>         4)

I'll have a play with that and report back.

Thanks.
--
Dan Langille : http://www.langille.org/
BSDCan - http://www.bsdcan.org/



В списке pgsql-performance по дате сообщения:

От: Duane Lee - EGOVX
Дата:
Сообщение: Re: is it possible to for the planner to optimize this
От: Tom Lane
Дата:
Сообщение: Re: pl/pgsql and Transaction Isolation