Re: Moving postgresql.conf tunables into 2003...

От: Bruce Momjian
Тема: Re: Moving postgresql.conf tunables into 2003...
Дата: ,
Msg-id: 200307201920.h6KJKQL10578@candle.pha.pa.us
(см: обсуждение, исходный текст)
Ответ на: Re: Moving postgresql.conf tunables into 2003...  (Sean Chittenden)
Список: pgsql-performance

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

Moving postgresql.conf tunables into 2003...  (Sean Chittenden, )
 Re: Moving postgresql.conf tunables into 2003...  (Rod Taylor, )
  Re: Moving postgresql.conf tunables into 2003...  (Sean Chittenden, )
 Re: Moving postgresql.conf tunables into 2003...  ("scott.marlowe", )
  Re: Moving postgresql.conf tunables into 2003...  (Brian Hirt, )
   Re: Moving postgresql.conf tunables into 2003...  (Sean Chittenden, )
    Re: Moving postgresql.conf tunables into 2003...  (Matthew Hixson, )
  Re: Moving postgresql.conf tunables into 2003...  (Sean Chittenden, )
   Re: Moving postgresql.conf tunables into 2003...  (Tom Lane, )
    Re: Moving postgresql.conf tunables into 2003...  (Sean Chittenden, )
 Re: Moving postgresql.conf tunables into 2003...  ("Michael Mattox", )
  Re: Moving postgresql.conf tunables into 2003...  (Sean Chittenden, )
   Re: Moving postgresql.conf tunables into 2003...  (Martin Foster, )
   Re: Moving postgresql.conf tunables into 2003...  (Bruce Momjian, )
 Re: Moving postgresql.conf tunables into 2003...  (Ron, )
 Re: Moving postgresql.conf tunables into 2003...  (Tom Lane, )
  Re: Moving postgresql.conf tunables into 2003...  (Sean Chittenden, )
   Re: Moving postgresql.conf tunables into 2003...  (Rod Taylor, )
   Re: Moving postgresql.conf tunables into 2003...  (Manfred Koizar, )
    Re: Moving postgresql.conf tunables into 2003...  (Sean Chittenden, )
     Re: Moving postgresql.conf tunables into 2003...  (Manfred Koizar, )
      Re: Moving postgresql.conf tunables into 2003...  (Sean Chittenden, )
       Re: Moving postgresql.conf tunables into 2003...  (Tom Lane, )
        Index correlation (was: Moving postgresql.conf tunables into 2003... )  (Manfred Koizar, )
     Use of multipart index with "IN"  (Rob Messer, )
      Re: Use of multipart index with "IN"  (Tom Lane, )
 Re: Moving postgresql.conf tunables into 2003...  (Josh Berkus, )
  Re: Moving postgresql.conf tunables into 2003...  (Tom Lane, )
  Re: Moving postgresql.conf tunables into 2003...  (Tom Lane, )
  Re: Moving postgresql.conf tunables into 2003...  (Tom Lane, )
  Re: Moving postgresql.conf tunables into 2003...  (Sean Chittenden, )
   Re: Moving postgresql.conf tunables into 2003...  (Josh Berkus, )
    Re: Moving postgresql.conf tunables into 2003...  (Sean Chittenden, )
     Re: Moving postgresql.conf tunables into 2003...  (Josh Berkus, )
   Re: Moving postgresql.conf tunables into 2003...  ("Matthew Nuzum", )
    Re: Moving postgresql.conf tunables into 2003...  (Michael Pohl, )
     Re: Moving postgresql.conf tunables into 2003...  (Martin Foster, )
     Re: Moving postgresql.conf tunables into 2003...  (Bruce Momjian, )
    Re: Moving postgresql.conf tunables into 2003...  (Chris Travers, )
     Re: Moving postgresql.conf tunables into 2003...  ("Jim C. Nasby", )
   Re: Moving postgresql.conf tunables into 2003...  (Andrew Sullivan, )
    Re: Moving postgresql.conf tunables into 2003...  ("Matthew Nuzum", )
     Re: Moving postgresql.conf tunables into 2003...  ("Michael Mattox", )
     Re: Moving postgresql.conf tunables into 2003...  (Tom Lane, )
      Re: Moving postgresql.conf tunables into 2003...  (Kaarel, )
       Re: Moving postgresql.conf tunables into 2003...  ("scott.marlowe", )
        Re: Moving postgresql.conf tunables into 2003...  (Martin Foster, )
  Re: Moving postgresql.conf tunables into 2003...  ("Matthew Nuzum", )

Keep in mind that if we auto-tune, we will only be able to do it for
some platforms, so we will need a table that shows which settings are
autotuned for each platform.

---------------------------------------------------------------------------

Sean Chittenden wrote:
> > I don't have much to add because I'm pretty new to Postgres and have
> > been soliciting advice here recently, but I totally agree with
> > everything you said.  I don't mind if it's in the postgres.conf file
> > or in a faq that is easy to find, I just would like it to be in one
> > place.  A good example of the need for this is when I was tuning
> > "effective_cache" I thought that was creating a cache for Postgres
> > when in fact as it was pointed out to me, it's just hinting to
> > postgres the size of the OS cache.  Lots of ways for people to get
> > really confused here.
>
> I looked through the src/doc/runtime.sgml for a good place to stick
> this and couldn't find a place that this seemed appropriate, but on
> FreeBSD, this can be determined with a great deal of precision in a
> programmatic manner:
>
> echo "effective_cache_size = $((`sysctl -n vfs.hibufspace` / 8192))"
>
> The same OID is available via C too.  It'd be slick if PostgreSQL
> could tune itself (on FreeBSD) at initdb time with the above code.  If
> Linux exports this info via /proc and can whip out the appropriate
> magic, even better.  An uncommented out good guess that shows up in
> postgresql.conf would be stellar and quite possible with the use of
> sed.
>
> Maybe an initdb switch could be added to have initdb tune the config
> it generates?  If a -n is added, have it generate a config and toss it
> to stdout?
>
>
> case `uname` in
> "FreeBSD")
>         echo "effective_cache_size = $((`sysctl -n vfs.hibufspace` / 8192))"
>         ;;
> *)
>         echo "Unable to automatically determine the effective cache size" >> /dev/stderr
>         ;;
> esac
>
>
> -sc
>
> --
> Sean Chittenden
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Don't 'kill -9' the postmaster
>

--
  Bruce Momjian                        |  http://candle.pha.pa.us
                 |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073


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

От: "Jeremy M. Guthrie"
Дата:
Сообщение: Re: Poor delete performance AFTER vacuum analyze
От: Bruce Momjian
Дата:
Сообщение: Re: [pgsql-advocacy] About the default performance