Re: [HACKERS] Changing the default configuration (was Re: [pgsql-advocacy]

[Jason Hihn]

Nutshell:
   Easy to install but is horribly slow.

   or

   Took a couple of minutes to configure and it rocks!

Since when is it easy to install on win32?
The easiest way I know of is through Cygwin, then you have to worry about
installing the IPC service (an getting the right version too!) I've
installed versions 6.1 to 7.1, but I almost gave up on the windows install.
At least in 6.x you had very comprehensive installation guide with a TOC.

Versus the competition which are you going to choose if you're a wanna-be
DBA? The one with all he hoops to jump through, or the one that comes with a
setup.exe?

Now I actually am in support of making it more aggressive, but it should
wait until we too have a setup.exe for the native windows port. (Changing it
on *n*x platforms is of little benefit because most benchmarks seem to run
it on w32 anyway :-( )

Just my $.02. I reserve the right to be wrong.
-J


---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster

Re: [pgsql-advocacy] [HACKERS] Changing the default configuration

[Jason Hihn]

Pardon my ignorance, but there's no way to auto-tune? Ship it with a thread
that gathers statistics and periodically re-tunes the database parameters.
Of course, be able to turn it off. People that actually take the time to run
tune manually will turn it off as to not have the overhead or interruption.
Those that don't care about pg_tune shouldn't care about having a thread
around retuning. Those that will care will tune manually.



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Bruce Momjian
Sent: Thursday, February 13, 2003 2:22 PM
To: Daniel Kalchev
Cc: PostgresSQL Hackers Mailing List; [EMAIL PROTECTED]
Subject: Re: [pgsql-advocacy] [HACKERS] Changing the default
configuration



I imagined they could run pgtune anytime after install to update those
performance parameters.  It gives them a one-stop location to at least
do minimal tuning, and as their load changes, they can run it again.

---

Daniel Kalchev wrote:
 Bruce Momjian said:
 [...]
   For example, we can ask them how many rows and tables they will be
   changing, on average, between VACUUM runs.  That will allow us set the
   FSM params.  We can ask them about using 25% of their RAM for shared
   buffers.  If they have other major apps running on the server or have
   small tables, we can make no changes.  We can basically ask them
   questions and use that info to set values.

 Bruce, this is an very good idea and such tool would simplify setup for
the
 me-too type of DBA - we should definitely try to attract them.

 However, how could one possibly answer the above question, if they setup
their
 database for the first time?

 What is more, these settings are on a per-installation, not per-database -
 which means, that if you have several small, but active databases and one
 large database the requirements will be very different.

 Nobody likes answering such questions when installing new software. You
might
 enjoy it the first few times, but then learn the 'answers' and don't even
 think what the question is. (we all know the answer :)

 Perhaps indeed a better idea is to have PostgreSQL itself collect usage
 statistics, and from time to time print 'suggestions' to the log file
(best in
 my opinion), or have these available via some query. These suggestions
should
 best reflect the of course require minimal intervention to the database
 system, such as restart etc.


 Daniel



 ---(end of broadcast)---
 TIP 6: Have you searched our list archives?

 http://archives.postgresql.org


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

---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster


---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?

http://www.postgresql.org/users-lounge/docs/faq.html