From: Scott Marlowe <scott.marlowe@gmail.com>
To: Erik Jones <erik@myemma.com>
Cc: Greg Smith <gsmith@gregsmith.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: [Again] Postgres performance problem
Date: Thu, 13 Sep 2007 11:39:55 -0500
Message-ID: <dcc563d10709130939w1428f5d1uf56faa615e212362@mail.gmail.com> (raw)
In-Reply-To: <81405E66-5110-4DA8-B315-D28EA124CDB6@myemma.com>
References: <46E636CB.8080008@rentalia.com>
<43393.192.121.104.48.1189495883.squirrel@zigo.dhs.org>
<46E64891.9080005@rentalia.com>
<20070911225242.GG38801@decibel.org>
<46E79865.906@rentalia.com>
<dcc563d10709121128o1e5883a9n96b1f9ed74901be9@mail.gmail.com>
<Pine.GSO.4.64.0709130130390.8547@westnet.com>
<81405E66-5110-4DA8-B315-D28EA124CDB6@myemma.com>
On 9/13/07, Erik Jones <erik@myemma.com> wrote:
> On Sep 13, 2007, at 12:58 AM, Greg Smith wrote:
>
> > On Wed, 12 Sep 2007, Scott Marlowe wrote:
> >
> >> I'm getting more and more motivated to rewrite the vacuum docs. I
> >> think a rewrite from the ground up might be best... I keep seeing
> >> people doing vacuum full on this list and I'm thinking it's as
> >> much because of the way the docs represent vacuum full as anything.
> >
> > I agree you shouldn't start thinking in terms of how to fix the
> > existing documentation. I'd suggest instead writing a tutorial
> > leading someone through what they need to know about their tables
> > first and then going into how vacuum works based on that data.
> >
> > As an example, people throw around terms like "index bloat" and
> > "dead tuples" when talking about vacuuming. The tutorial I'd like
> > to see somebody write would start by explaining those terms and
> > showing how to measure them--preferably with a good and bad example
> > to contrast. The way these terms are thrown around right now, I
> > don't expect newcomers to understand either the documentation or
> > the advice people are giving them; I think it's shooting over their
> > heads and what's needed are some walkthroughs. Another example I'd
> > like to see thrown in there is what it looks like when you don't
> > have enough FSM slots.
>
> Isn't that the point of the documentation? I mean, if the existing,
> official manual has been demonstrated (through countless mailing list
> help requests) to not sufficiently explain a given topic, shouldn't
> it be revised? One thing that might help is a hyperlinked glossary
> so that people reading through the documentation can go straight to
> the postgres definition of dead tuple, index bloat, etc.
Yes and no. The official docs are more of a technical specification.
Short, simple and to the point so that if you know mostly what you're
doing you don't have to wade through a long tutorial to find the
answer. I find MySQL's documentation frustrating as hell because I
can never find just the one thing I wanna look for. Because it's all
written as a tutorial. I.e. I have to pay the "stupid tax" when I
read their docs.
What I want to do is two fold. 1: fix the technical docs so they have
better explanations of each of the topics, without turning them into
huge tutorials. 2: Write a vacuuming tutorial that will be useful
should someone be new to postgresql and need to set up their system.
I think the tutorial should be broken into at least two sections, a
quick start guide and an ongoing maintenance and tuning section.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: scott.marlowe@gmail.com, erik@myemma.com, gsmith@gregsmith.com
Subject: Re: [Again] Postgres performance problem
In-Reply-To: <dcc563d10709130939w1428f5d1uf56faa615e212362@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox