Skip site navigation (1)
Skip section navigation (2)
Peripheral Links
Header And Logo
|
Site Navigation
Re: Slow sequential scans on one DB but not another; fragmentation?
- From: Stephen Harris <lists(at)spuddy(dot)org>
- To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
- Cc: Postgres General <pgsql-general(at)postgresql(dot)org>
- Subject: Re: Slow sequential scans on one DB but not another; fragmentation?
- Date: Fri, 30 Mar 2007 18:16:00 -0400
On Wed, Mar 28, 2007 at 11:36:27AM -0400, Tom Lane wrote: > Stephen Harris <lists(at)spuddy(dot)org> writes: > > INFO: "sweep_users": found 835831 removable, 972662 nonremovable row versions in 2890304 pages > 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 OK, we were doing a code release today and so had a change window open. We ran a cluster command on this table. It took 15 minutes to complete, and the number of pages went down to 27,000 - ie by a factor of 100. "select count(*)" took 4 seconds instead of 220, giving us a 55 times speed increase. We'll keep our eye on this but since it was relatively quick we might schedule a weekly cluster "just in case". Thanks! -- rgds Stephen
- References:
- Slow sequential scans on one DB but not another; fragmentation?
- From: Stephen Harris
- Re: Slow sequential scans on one DB but not another; fragmentation?
- From: Tom Lane
- Re: Slow sequential scans on one DB but not another; fragmentation?
- From: Stephen Harris
- Re: Slow sequential scans on one DB but not another; fragmentation?
- From: Tom Lane
- Slow sequential scans on one DB but not another; fragmentation?
- Prev by Date: Re: PANIC: unexpected hash relation size
- Next by Date: Anyone know where I can get an 8.2.3 binary for ubuntu?
- Previous by thread: Re: Slow sequential scans on one DB but not another; fragmentation?
- Next by thread: Re: Slow sequential scans on one DB but not another; fragmentation?
- Indexes: