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

Re: perf pb solved only after pg_dump and restore

From: Markus Schaber <schabi(at)logix-tt(dot)com>
To: Guillaume Cottenceau <gc(at)mnc(dot)ch>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: perf pb solved only after pg_dump and restore
Date: 2006-08-28 09:28:23
Message-ID: 44F2B737.7070301@logix-tt.com (view raw or flat)
Thread:
Lists: pgsql-performance
Hi, Guillaume

Guillaume Cottenceau wrote:

> We noticed a slowdown on our application while traffic was kinda
> heavy. The logics after reading the docs commanded us to trim the
> enlarged tables, run VACUUM ANALYZE and then expect fast
> performance again; but it wasn't the case[1].

What exactly do you mean with "trim the enlarged tables"?

> Out of the blue, we dumped the database, removed it, recreated
> from the restore, and now the performance is lightning fast
> again.
> 
> Does it look familiar to anyone? I thought running VACUUM ANALYZE
> after a trim should be enough so that pg has assembled the data
> and has good statistical knowledge of the tables contents..

This looks like either your free_space_map setting is way to low, or you
have index bloat.

Maybe a VACUUM FULL fullowed by a REINDEX will have solved your problem.

It also might make sense to issue a CLUSTER instead (which combines the
effects of VACUUM FULL, REINDEX and physically reordering the data).

When the free_space_map is to low, VACUUM ANALYZE should have told you
via a warning (at least, if your logging is set appropriately).


HTH,
Markus
-- 
Markus Schaber | Logical Tracking&Tracing International AG
Dipl. Inf.     | Software Development GIS

Fight against software patents in EU! www.ffii.org www.nosoftwarepatents.org

In response to

Responses

pgsql-performance by date

Next:From: Guillaume CottenceauDate: 2006-08-28 09:43:16
Subject: Re: perf pb solved only after pg_dump and restore
Previous:From: Guillaume CottenceauDate: 2006-08-28 08:14:52
Subject: perf pb solved only after pg_dump and restore

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