Skip site navigation (1) Skip section navigation (2)

Re: [Again] Postgres performance problem

From: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>
To: "Erik Jones" <erik(at)myemma(dot)com>
Cc: "Greg Smith" <gsmith(at)gregsmith(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: [Again] Postgres performance problem
Date: 2007-09-13 16:39:55
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On 9/13/07, Erik Jones <erik(at)myemma(dot)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.

In response to


pgsql-performance by date

Next:From: Brad NicholsonDate: 2007-09-13 16:52:21
Subject: Re: Long Running Commits - Not Checkpoints
Previous:From: Brad NicholsonDate: 2007-09-13 16:19:45
Subject: Re: Long Running Commits - Not Checkpoints

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group