Kevin,
# maintenance_work_mem = 256MB #webserver with 2GB RAM
Well, that was before multiple autovacuum workers. Now, you'd want it
lower. But ... it's better for vacuum to finish quickly than to drag
on. Vacuum uses more I/O than it does RAM.
But I'm amazed by this, too:
#
Peter,
Well, my original implementation of GUC had an empty default configuration
file, which was later craptaculated to its current form based on seemingly
popular demand. I am very happy to work back toward the empty state, and
there appears to be growing support for that.
I'd prefer a
David Fetter wrote:
And we're back to man pages and CHM files.
How big a project would that latter be?
CHM files already exist. (At least I think that CHM == HTML Help == Windows
help system.)
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
David Fetter wrote:
And we're back to man pages and CHM files.
So, did anyone else try to generate man pages? I did make man and ran
into several issues.
The first is that D2MDIR needs to be specified manually. I assume this
is how everyone does it, so I did that.
The second is that the
Alvaro Herrera wrote:
So, did anyone else try to generate man pages?
Before we get too excited here: Man pages are only built/buildable from
refentry elements. You can't just go and convert some arbitrary section or
chapter into a man page. So there is a bit of work and invention necessary
On Tue, Aug 19, 2008 at 9:40 PM, Tom Lane [EMAIL PROTECTED] wrote:
Robert Treat [EMAIL PROTECTED] writes:
I'd still like to see us adopt the proposal from some time ago where
we stop commenting out the parameters at all, but short of that,
hiding options seems about the worst choice we could
Alvaro Herrera wrote:
Dave Page wrote:
On Tue, Aug 19, 2008 at 10:03 PM, Tom Lane [EMAIL PROTECTED] wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm, let me suggest providing it as a manpage for postgresql.conf, i.e.,
you run man postgresql.conf and it gives you this manpage documenting
On Wed, Aug 20, 2008 at 4:40 AM, Joshua Drake [EMAIL PROTECTED] wrote:
On Tue, 19 Aug 2008 23:32:34 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
On idea is for postgresql.conf to merely include other files:
include 'sharedmem.conf'
include
Peter Eisentraut wrote:
On Tuesday 19 August 2008 19:12:16 Tom Lane wrote:
Well, why not just make a one-eighty and say that the default
postgresql.conf is *empty* (except for whatever initdb puts into it)?
Well, my original implementation of GUC had an empty default
configuration
file,
Dave Page wrote:
On Wed, Aug 20, 2008 at 4:40 AM, Joshua Drake [EMAIL PROTECTED] wrote:
I am not arguing for this but if we went down that route it does buy us
the ability to compartmentalize the entire conf.. so you have:
memory_settings.conf
logging.conf
maintenance.conf
Would
Alvaro Herrera wrote:
Dave Page wrote:
On Wed, Aug 20, 2008 at 4:40 AM, Joshua Drake [EMAIL PROTECTED] wrote:
I am not arguing for this but if we went down that route it does buy us
the ability to compartmentalize the entire conf.. so you have:
memory_settings.conf
logging.conf
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Well, there seems to be a very substantial body of opinion that says
we *do* need to hide uninteresting options.
more to the point... not just uninteresting but dangerous for the
uninformed ones...
i have seen to many people turning off
On Wednesday 20 August 2008 02:22:26 Jaime Casanova wrote:
On Tue, Aug 19, 2008 at 9:40 PM, Tom Lane [EMAIL PROTECTED] wrote:
Robert Treat [EMAIL PROTECTED] writes:
I'd still like to see us adopt the proposal from some time ago where
we stop commenting out the parameters at all, but short
Greg Sabino Mullane [EMAIL PROTECTED] writes:
# foobar: Adjusts the foobariness of the database
#
# This uses units of baz from 1-10, with 10 being the strongest
#
# Changing this setting requires a reload
# This setting may also be changed per session
# The default value is 5
#
# For
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
So your plan is that postgresql.conf will be approximately two thousand
lines long, before the user has ever touched it at all? (Two hundred
or so GUC variables and ten lines of comments for each one)
Sure, why not? Clarity should always
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
One more benefit of a small file is that it makes it easier to ask someone
please attach a copy of your postgresql.conf file; rather than please
send the output of grep -v '^[]*#' postgresql.conf | grep = or worse
Can you recall what
On Wed, 20 Aug 2008 15:49:39 -
Greg Sabino Mullane [EMAIL PROTECTED] wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Sure, why not? Clarity should always trump brevity. The only people
who gain from a comment-less file are the ones who are already expert
in it.
You are
Greg Sabino Mullane [EMAIL PROTECTED] writes:
So your plan is that postgresql.conf will be approximately two thousand
lines long, before the user has ever touched it at all? (Two hundred
or so GUC variables and ten lines of comments for each one)
Sure, why not? Clarity should always trump
On Wed, Aug 20, 2008 at 09:08:02AM -0700, Joshua D. Drake wrote:
On Wed, 20 Aug 2008 15:49:39 -
Greg Sabino Mullane [EMAIL PROTECTED] wrote:
Sure, why not? Clarity should always trump brevity. The only
people who gain from a comment-less file are the ones who are
already expert in
Peter Eisentraut wrote:
I seem to recall that there was general support for installing a smaller
default postgresql.conf file with only, say, a dozen parameters mentioned for
initial tuning. The complete file can stay as a sample. Any objections to
that? (Let's not discuss quite yet exactly
Hans-Juergen Schoenig wrote:
alternatively we could use some sort of #include mechanism to split
most important and not so important.
We already have an include mechanism.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting,
Alvaro Herrera wrote:
Hans-Juergen Schoenig wrote:
alternatively we could use some sort of #include mechanism to split
most important and not so important.
We already have an include mechanism.
Using that to include a file that's full of comments anyway (which is
all that's left in
On Tue, 19 Aug 2008 17:11:49 +0200
Magnus Hagander [EMAIL PROTECTED] wrote:
Alvaro Herrera wrote:
Hans-Juergen Schoenig wrote:
alternatively we could use some sort of #include mechanism to
split most important and not so important.
We already have an include mechanism.
Using
Joshua Drake [EMAIL PROTECTED] writes:
Magnus Hagander [EMAIL PROTECTED] wrote:
Using that to include a file that's full of comments anyway (which is
all that's left in postgresql.conf at this time, I'm sure) just seems.
Well. Sub-optimal.
Yes but part of this idea is valid. The fact is the
On Tue, 19 Aug 2008 12:12:16 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Joshua Drake [EMAIL PROTECTED] writes:
Magnus Hagander [EMAIL PROTECTED] wrote:
Yes but part of this idea is valid. The fact is the majority of the
postgresql.conf parameters don't need to be in there by default. It
Joshua Drake [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
Well, why not just make a one-eighty and say that the default
postgresql.conf is *empty* (except for whatever initdb puts into it)?
I guess it would depend on what initdb puts into it.
Per the code:
max_connections
Tom,
Well, why not just make a one-eighty and say that the default
postgresql.conf is *empty* (except for whatever initdb puts into it)?
I've never thought that the current contents were especially useful
as documentation; the kindest thing you can say about 'em is that they
are duplicative of
On Tue, 19 Aug 2008 12:48:20 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Joshua Drake [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] wrote:
Well, why not just make a one-eighty and say that the default
postgresql.conf is *empty* (except for whatever initdb puts into
it)?
I guess it
Josh Berkus [EMAIL PROTECTED] wrote:
Attached is the postgresql.conf.simple I used in my presentaiton. It
has an egregious math error in it (see if you can find it) but should
give you the general idea.
Well, this sure looks scary:
# maintenance_work_mem = 256MB #webserver with 2GB
Joshua Drake [EMAIL PROTECTED] writes:
If we move to the above route, we end up in an environment with a
single source for official documentation and we can always point to
that.
Yeah, the fundamental point here is whether or not postgresql.conf
should be trying to serve as part of our system
On Tue, Aug 19, 2008 at 1:17 PM, Kevin Grittner
[EMAIL PROTECTED] wrote:
Josh Berkus [EMAIL PROTECTED] wrote:
But I'm amazed by this, too:
# max_connections = 700 # web application database
How many CPUs and spindles are you assuming there?
My testing and experience suggest applications
On Tue, 19 Aug 2008 13:22:34 -0400
Tom Lane [EMAIL PROTECTED] wrote:
I'm really not in favor of having comments in the conf file that try
to tell you about stuff you might want to set, much less why. That
task properly belongs to some kind of introductory chapter in the
SGML docs. Novice
On Tue, 19 Aug 2008 12:17:46 -0500
Kevin Grittner [EMAIL PROTECTED] wrote:
Well, this sure looks scary:
# maintenance_work_mem = 256MB #webserver with 2GB RAM
I would agree. 2GB isn't that much memory as it is and that is a fairly
heft amount of maintenance_work_mem. This isn't the days
On Tuesday 19 August 2008 19:12:16 Tom Lane wrote:
Well, why not just make a one-eighty and say that the default
postgresql.conf is *empty* (except for whatever initdb puts into it)?
Well, my original implementation of GUC had an empty default configuration
file, which was later craptaculated
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
I'm really not in favor of having comments in the conf file that try to
tell you about stuff you might want to set, much less why. That task
properly belongs to some kind of introductory chapter in the SGML docs.
Novice DBAs are unlikely
Greg Sabino Mullane [EMAIL PROTECTED] writes:
I like Josh B's version a lot. It's not perfect (I'd add a URL for
each config for example), but it's a great start.
Josh B's approach is great until people start making changes that are
unrelated to (or perhaps even contradictory to) his comments.
On Tue, 19 Aug 2008 19:12:47 -
Greg Sabino Mullane [EMAIL PROTECTED] wrote:
Ugh, you are heading in the wrong direction. The configuration file
should be well documented: moving the documentation further away
from it is the wrong idea, especially if it means firing up a web
browser to do
On Tuesday 19 August 2008 22:12:47 Greg Sabino Mullane wrote:
moving the documentation further away from it is the wrong idea,
especially if it means firing up a web browser to do so.
I can see that argument, but I think we can quite simply solve it if we
provide a plain-text version of the
I'm really not in favor of having comments in the conf file that try to
tell you about stuff you might want to set, much less why. That task
properly belongs to some kind of introductory chapter in the SGML docs.
Novice DBAs are unlikely even to *find* the config file, let alone look
inside
Peter Eisentraut wrote:
On Tuesday 19 August 2008 22:12:47 Greg Sabino Mullane wrote:
moving the documentation further away from it is the wrong idea,
especially if it means firing up a web browser to do so.
I can see that argument, but I think we can quite simply solve it if we
provide
On Tue, 19 Aug 2008 15:43:11 -0400
Alvaro Herrera [EMAIL PROTECTED] wrote:
Peter Eisentraut wrote:
On Tuesday 19 August 2008 22:12:47 Greg Sabino Mullane wrote:
moving the documentation further away from it is the wrong idea,
especially if it means firing up a web browser to do so.
Peter Eisentraut wrote:
On Tuesday 19 August 2008 22:12:47 Greg Sabino Mullane wrote:
Text space is cheap,
I'd offer the alternative theory that anything that is longer than one screen
is overwhelming and unwieldy.
One more benefit of a small file is that it makes it easier to ask someone
Alvaro Herrera [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
I can see that argument, but I think we can quite simply solve it if we
provide a plain-text version of the configuration chapter of the
documentation.
Hmm, let me suggest providing it as a manpage for postgresql.conf, i.e.,
On Tue, 19 Aug 2008 17:03:48 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
I can see that argument, but I think we can quite simply solve it
if we provide a plain-text version of the configuration chapter of
the documentation.
On Tue, Aug 19, 2008 at 10:03 PM, Tom Lane [EMAIL PROTECTED] wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Peter Eisentraut wrote:
I can see that argument, but I think we can quite simply solve it if we
provide a plain-text version of the configuration chapter of the
documentation.
Hmm,
On Tue, 19 Aug 2008, Josh Berkus wrote:
Well, that doesn't help unless we either provide a .conf generation tool
(something I favor) or docs somewhere which explain which are the variables
to be the most concerned with instead of making users read through all 218 of
them.
The design for a
Dave Page wrote:
On Tue, Aug 19, 2008 at 10:03 PM, Tom Lane [EMAIL PROTECTED] wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Hmm, let me suggest providing it as a manpage for postgresql.conf, i.e.,
you run man postgresql.conf and it gives you this manpage documenting
every option.
On Tue, Aug 19, 2008 at 07:12:47PM -, Greg Sabino Mullane wrote:
I'm really not in favor of having comments in the conf file that
try to tell you about stuff you might want to set, much less why.
That task properly belongs to some kind of introductory chapter in
the SGML docs. Novice
On Tue, Aug 19, 2008 at 09:39:39PM +0300, Peter Eisentraut wrote:
On Tuesday 19 August 2008 19:12:16 Tom Lane wrote:
Well, why not just make a one-eighty and say that the default
postgresql.conf is *empty* (except for whatever initdb puts into it)?
Well, my original implementation of GUC
On Tuesday 19 August 2008 14:39:39 Peter Eisentraut wrote:
On Tuesday 19 August 2008 19:12:16 Tom Lane wrote:
Well, why not just make a one-eighty and say that the default
postgresql.conf is *empty* (except for whatever initdb puts into it)?
Well, my original implementation of GUC had an
Robert Treat [EMAIL PROTECTED] writes:
I'd still like to see us adopt the proposal from some time ago where
we stop commenting out the parameters at all, but short of that,
hiding options seems about the worst choice we could make.
Well, there seems to be a very substantial body of opinion
Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
I'd still like to see us adopt the proposal from some time ago where
we stop commenting out the parameters at all, but short of that,
hiding options seems about the worst choice we could make.
Well, there seems to be a very
Bruce Momjian [EMAIL PROTECTED] writes:
On idea is for postgresql.conf to merely include other files:
include 'sharedmem.conf'
include 'compat.conf'
...
That would definitely add complexity ... what would it buy in return?
regards, tom lane
--
Sent
On Tue, 19 Aug 2008 23:32:34 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
On idea is for postgresql.conf to merely include other files:
include 'sharedmem.conf'
include 'compat.conf'
...
That would definitely add complexity ... what would
On Wed, 20 Aug 2008 00:10:35 -0400 (EDT)
Bruce Momjian [EMAIL PROTECTED] wrote:
Another option would be to break up the conf like the above but do
not include any of them in the main postgresql.conf (which is how I
would argue it should be done). Thus if you want to modify logging,
you
Joshua Drake wrote:
On Tue, 19 Aug 2008 23:32:34 -0400
Tom Lane [EMAIL PROTECTED] wrote:
Bruce Momjian [EMAIL PROTECTED] writes:
On idea is for postgresql.conf to merely include other files:
include 'sharedmem.conf'
include 'compat.conf'
...
That would definitely add
56 matches
Mail list logo
