Re: Slow sequential scans on one DB but not another; fragmentation? - Mailing list pgsql-general

From Tom Lane
Subject Re: Slow sequential scans on one DB but not another; fragmentation?
Date
Msg-id 25274.1175096187@sss.pgh.pa.us
Whole thread Raw
In response to Re: Slow sequential scans on one DB but not another; fragmentation?  (Stephen Harris <lists@spuddy.org>)
Responses Re: Slow sequential scans on one DB but not another; fragmentation?  (Stephen Harris <lists@spuddy.org>)
Re: Slow sequential scans on one DB but not another; fragmentation?  (Stephen Harris <lists@spuddy.org>)
List pgsql-general
Stephen Harris <lists@spuddy.org> writes:
> INFO:  "sweep_users": found 835831 removable, 972662 nonremovable row versions in 2890304 pages
> DETAIL:  0 dead row versions cannot be removed yet.
> There were 112212932 unused item pointers.

Oy, that's one bloated table ... only one live row in every three or so pages.

Probably a CLUSTER is the most effective way of cleaning it up.  Once
you get it down to size, revisit your vacuuming policy, because it
definitely isn't getting vacuumed often enough.

            regards, tom lane

pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: unexpected data beyond EOF and character encoding
Next
From: Joseph Shraibman
Date:
Subject: Re: redhat debug info