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
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:
# max_conne
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
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
here.
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 P
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 s
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 e
"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 alway
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
-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 rec
-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
"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
> #
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,
-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 t
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
>>> log
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.c
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, whi
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'
>>
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
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
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'
> > > ...
> >
> > Tha
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,
>
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
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
--
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
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
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
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
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.
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
> >> ev
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 pg
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
>>> document
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 do
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.con
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
"
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
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
> p
> 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
> ins
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 c
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
"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 comme
-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 unlikel
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
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 d
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. Novi
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 ap
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 s
>>> 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 wi
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
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 t
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_connec
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 defa
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 f
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"
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
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, Consul
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
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 which parameters are the
57 matches
Mail list logo
