user guide

On 6 Aug 2001, Tony Grant wrote:

hello,

This weekend I read the User guide front to back. I hadn't done that
since 6.2 or thereabouts...

I have one request for improvement:

<snip>

I have a suggestion, as well: I think the PostgreSQL documentatio could
use a section that discusses all the maintenance issues in one place.
Documentation for VACUUM is stuck in the Reference section, when I think
it makes sense to also cover it in the Admin Section. Here's waht I'd like
to see in Adin:

Backup and Restor (already there)
Database Mainentence
VACUUM
VACUUM ANALYZE
Rebuilding Indexes (Does this even apply to PG?)

Thanks,

David

--
David Wheeler AIM: dwTheory
David@Wheeler.net ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org

David Wheeler <David@Wheeler.net> writes:

I have a suggestion, as well: I think the PostgreSQL documentatio could
use a section that discusses all the maintenance issues in one place.

I agree. Do I hear a volunteer to write it?

regards, tom lane

David Wheeler writes:

I have a suggestion, as well: I think the PostgreSQL documentatio could
use a section that discusses all the maintenance issues in one place.

This is already on the TODO list.

--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter

Hi,

I have a suggestion, as well: I think the PostgreSQL documentatio could
use a section that discusses all the maintenance issues in one place.

I agree. Do I hear a volunteer to write it?

I'd be interested in looking at it.
Is it just this todo item : Add mention of VACUUM, log rotation to
Administrator's Guide ?

-----------------
Chris Smith
http://www.squiz.net/

I have a suggestion, as well: I think the PostgreSQL documentatio could
use a section that discusses all the maintenance issues in one place.

This is already on the TODO list.

I've started expanding the Admin chapter on database recovery (expanding
was easy; it has been "Any volunteers to write this?" for two or three
years now). At the moment, I've split the info into two chapters on
"Failure" (discussing various failure scenarios) and "Recovery".

Comments and organizational suggestions are welcome. Will commit
sometime soon so others can contribute if they would like.

- Thomas

Chris <csmith@squiz.net> writes:

I have a suggestion, as well: I think the PostgreSQL documentatio could
use a section that discusses all the maintenance issues in one place.

I agree. Do I hear a volunteer to write it?

I'd be interested in looking at it.
Is it just this todo item : Add mention of VACUUM, log rotation to
Administrator's Guide ?

That was added as a result of the thread starting at
http://fts.postgresql.org/db/mw/msg.html?mid=115811

There are two things I think we need: one is a discussion of each of
these topics (which AFAIR are presently discussed nowhere); the other
is a short "checklist of maintenance concerns" that links to longer
discussions of each relevant topic. For example, there's already a
discussion of backup methods, but it'd be good if that were listed in a
checklist of things for the budding admin to think about.

Or you could reorganize the Admin Guide so that backup and these other
things are sections in a Maintenance chapter. Not sure if that'd be
better.

regards, tom lane

Thomas Lockhart writes:

I've started expanding the Admin chapter on database recovery (expanding
was easy; it has been "Any volunteers to write this?" for two or three
years now). At the moment, I've split the info into two chapters on
"Failure" (discussing various failure scenarios) and "Recovery".

Seems like that should be only one chapter.

--
Peter Eisentraut peter_e@gmx.net http://funkturm.homeip.net/~peter

I've started expanding the Admin chapter on database recovery (expanding
was easy; it has been "Any volunteers to write this?" for two or three
years now). At the moment, I've split the info into two chapters on
"Failure" (discussing various failure scenarios) and "Recovery".

Seems like that should be only one chapter.

Yes, maybe. Easy enough to merge back together. I split them because
there is not a one to one correspondence between potential failures and
recovery procedures.

- Thomas