Re: perf pb solved only after pg_dump and restore - Mailing list pgsql-performance

From Markus Schaber
Subject Re: perf pb solved only after pg_dump and restore
Date
Msg-id 44F2EC0C.7090407@logix-tt.com
Whole thread Raw
In response to Re: perf pb solved only after pg_dump and restore  (Guillaume Cottenceau <gc@mnc.ch>)
Responses Re: perf pb solved only after pg_dump and restore
List pgsql-performance
Hi, Guillaume,

Guillaume Cottenceau wrote:

> About REINDEX: is it ok to consider that REINDEX is to indexes
> what VACUUM FULL is to table data, because it cleans up unused
> index pages?

Yes, roughly speaking.

>> And AFAICS you're not running it on a regular basis so your database
>> was probably completely bloated which means:
>> - bloated indexes,
>> - bloated tables (ie a lot of fragmentation in the pages which means
>> that you need far more pages to store the same data).
>
> I suppose that table fragmentation occurs when DELETE are
> interleaved with INSERT?

Yes, and it gets ugly as soon as the fsm setting is to low / VACUUM
frequency is to low, so it cannot keep up.

Big bunches of UPDATE/DELETE that hit more than, say 20% of the table
between VACUUM runs, justify a VACUUM FULL in most cases.

> VACUUM ANALYZE is normally run overnight (each night). Is it not
> regular enough? There can be hundreds of thousands of statements
> a day.

Which PostgreSQL version are you using? Maybe you should consider
autovacuum (which is a contrib module at least since 7.4, and included
in the server since 8.1). If you think that vacuum during working hours
puts too much load on your server, there are options to tweak that, at
least in 8.1.

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

pgsql-performance by date:

Previous
From: Guillaume Cottenceau
Date:
Subject: Re: perf pb solved only after pg_dump and restore
Next
From: Alvaro Herrera
Date:
Subject: Re: Postgre SQL 7.1 cygwin performance issue.