> > 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?

Or it proves that no one bothers to read the docs.

> > 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.

Yes! MySQL documentation is maddening.

This is why, I suspect, for products like Informix and DB2 IBM publishes
two manuals (or roughly equivalent to two manuals): a "guide" and a
"reference".

> written as a tutorial. I.e. I have to pay the "stupid tax" when I
> read their docs.

Yep.

> 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.



---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



Gavin M. Roy escribió:
> How many backends do you have at any given time? Have you tried using
> something like pgBouncer to lower backend usage? How about your IO
> situation? Have you run something like sysstat to see what iowait is
> at?

backends arround 50 -100 I don't use pgBouncer yet.
Sysstat reports veeery low io.

Right now Im checking out fsm parameter, as Scott recomended. Seems
there is the problem.



>
> On 9/11/07, Ruben Rubio <ruben@rentalia.com> wrote:
>
> Hi,
>
> I having the same problem I told here a few weeks before. Database is
> using too much resources again.
>
> I do a vacumm full each day, but seems it is not working. I am preparing
> an update to postgres 8.2.4 (actually I am using at 8.1.3, and tests for
> update will need several days)
>
> Last time I had this problem i solved it stopping website, restarting
> database, vacuumm it, run again website. But I guess this is going to
> happen again.
>
> I would like to detect and solve the problem. Any ideas to detect it?
>
> Thanks in advance,
>
>
>
>>
>>
- ---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly
>>
>>
>>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG7mx7Io1XmbAXRboRAn0VAJ4sGc1KCNlsbrybVbY/WfB+3XWBbwCfb7Z/
WNGyJCRo6zd26uR6FB6SA8o=
=SYzs
-----END PGP SIGNATURE-----


---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

On Wed, Sep 12, 2007 at 03:01:12PM -0500, Erik Jones wrote:
>
> On Sep 12, 2007, at 2:19 PM, Frank Schoep wrote:
>
> >On Sep 12, 2007, at 9:07 PM, Scott Marlowe wrote:
> >>On 9/12/07, Mikko Partio <mpartio@gmail.com> wrote:
> >>>?
> >>>Aren't you mixing up REINDEX and CLUSTER?
> >>
> >>?
> >>Either one does what a vacuum full did / does, but generally does
> >>it better.
> >
> >On topic of REINDEX / VACUUM FULL versus a CLUSTER / VACUUM ANALYZE
> >I'd like to ask if CLUSTER is safe to run on a table that is in
> >active use.
> >
> >After updating my maintenance scripts from a VACUUM FULL (add me to
> >the list) to CLUSTER (which improves performance a lot) I noticed I
> >was getting "could not open relation ?" errors in the log while the
> >scripts ran so I reverted the change. This was on 8.1.9.
>
> You'd probably see the same behavior on 8.2.x. CLUSTER is not
> transactionally safe so you don't want to run CLUSTER on tables that
> are actively being used. I believe that's been fixed for 8.3.

Actually, that's a bit over-conservative... what happens prior to 8.3 is
that CLUSTER rewrites the table using it's XID for everything. That can
break semantics for any transactions that are running in serializable
mode; if you're just using the default isolation level of read
committed, you're fine with CLUSTER.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.3 (FreeBSD)

iD8DBQFG7nHudO30qud8SkgRAiswAKCgoMiT80Ei+6R/ZmAGYsQU/OBqGACg2GV5
3712UJ7hpSYBwMHeKFQh1yw=
=Gpfr
-----END PGP SIGNATURE-----

On Thu, Sep 13, 2007 at 01:58:10AM -0400, 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.

Take a look at the stuff at http://decibel.org/~decibel/pervasive/, it'd
hopefully provide a useful starting point.
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.3 (FreeBSD)

iD8DBQFG7nK3dO30qud8SkgRAp4fAKCnj8v8Lq+uNr/vMr/fHCNaDlv27ACfWwXA
MSu4PBo9tIjh8S+8ltZUFFg=
=j6wC
-----END PGP SIGNATURE-----

On Mon, 2007-09-17 at 07:27 -0500, Decibel! wrote:

> Take a look at the stuff at http://decibel.org/~decibel/pervasive/, it'd
> hopefully provide a useful starting point.


A bit offtrack, but I was reading the articles and noticed this in the
bottom. Is this a typo or ...


Making PostreSQL pervasive© 2005 Pervasive Software Inc
^^^^^^^^^



---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend