Re: How to VACUUM this table? "998994633 estimated total rows"

From: Guido Barosio <gbarosio(at)gmail(dot)com>
To: Chris Browne <cbbrowne(at)acm(dot)org>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: How to VACUUM this table? "998994633 estimated total rows"
Date: 2006-02-13 12:35:40
Message-ID: f7f6b4c70602130435t16cdaf2eg43c44cda9e9c50e2@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin pgsql-hackers

quote: " If you are quite sure it has few if any dead tuples, it might be
something to try to avoid VACUUMing except as needed to evade the 2^31
transaction limit..."

You may use the pg_stattuple software, included in the /contrib . This will
show you the current scenery, and whether you shall clean or not dead
tuples.

Best regards,
Guido.

On 2/12/06, Chris Browne <cbbrowne(at)acm(dot)org> wrote:
>
> an(at)mediaroot(dot)de (Aldor) writes:
> > I'm just curious about a VACUUM plan of this table:
> >
> > 1st) When to do VAUUM?
> > 2nd) How often to do VACUUM?
> > 3rd) With which postgresql.conf paremeters to set up vacuum?
> > 4th) When to do a VACUUM FULL?
> > 5th) Can autovacuum of 8.1 be used in this case?
> >
> > I'm a little bit afraid about the size of the table, but I think
> > somebody should have a solution...
> >
> > Here is the complete ANALYZE output of the table:
> >
> > INFO: "tbl1": scanned 300 of 27744713 pages, containing 10802 live rows
> > and 0 dead rows; 300 rows in sample, 998994633 estimated total rows
> >
> > The size of the data is 340 GB, this are 40% of the disk-array.
>
> Vacuuming this table is likely to take a rather long time. Hours and
> hours; possibly multiple days.
>
> I don't think you'll *ever* want to VACUUM FULL this table; I'm not
> sure you ever want autovacuum to process it either.
>
> I instead think you want to choose a time which seems best to start a
> Very Long Transaction to issue a VACUUM ANALYZE on it.
>
> If you are quite sure it has few if any dead tuples, it might be
> something to try to avoid VACUUMing except as needed to evade the 2^31
> transaction limit...
>
> I am not sure that's the only opinion you ought to consider on it...
> --
> (reverse (concatenate 'string "moc.enworbbc" "@" "enworbbc"))
> http://cbbrowne.com/info/sap.html
> Why are there interstate highways in Hawaii?
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo(at)postgresql(dot)org so that your
> message can get through to the mailing list cleanly
>

--
/"\ ASCII Ribbon Campaign .
\ / - NO HTML/RTF in e-mail .
X - NO Word docs in e-mail .
/ \ -----------------------------------------------------------------

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Chris Hoover 2006-02-13 14:50:10 constraint_exclusion on OLTP tables
Previous Message Tsirkin Evgeny 2006-02-13 08:59:32 Re: Need query parameter in logs

Browse pgsql-hackers by date

  From Date Subject
Next Message Mark Woodward 2006-02-13 12:57:24 Re: Why don't we allow DNS names in pg_hba.conf?
Previous Message Sergey E. Koposov 2006-02-13 12:34:11 Re: FW: PGBuildfarm member snake Branch HEAD Status changed