Re: Why will vacuum not end? - Mailing list pgsql-performance

From Manfred Koizar
Subject Re: Why will vacuum not end?
Date
Msg-id l40m80ta1765qtiif17lj0uh1039ii4kdv@email.aon.at
Whole thread Raw
In response to Re: Why will vacuum not end?  ("Shea,Dan [CIS]" <Dan.Shea@ec.gc.ca>)
List pgsql-performance
On Sat, 24 Apr 2004 15:58:08 -0400, "Shea,Dan [CIS]" <Dan.Shea@ec.gc.ca>
wrote:
>There were defintely 219,177,133 deletions.
>The deletions are most likely from the beginning, it was based on the
>reception_time of the data.
>I would rather not use re-index, unless it is faster then using vacuum.

I don't know whether it would be faster.  But if you decide to reindex,
make sure sort_mem is *huge*!

>What do you think would be the best way to get around this?
>Increase vacuum_mem to a higher amount 1.5 to 2 GB or try a re-index (rather
>not re-index so that data can be queried without soing a seqscan).

Just out of curiosity:  What kind of machine is this running on?  And
how long does a seq scan take?

>Once the index is cleaned up, how does vacuum handle the table?

If you are lucky VACUUM frees half the index pages.  And if we assume
that the most time spent scanning an index goes into random page
accesses, future VACUUMs will take "only" 30000 seconds per index scan.

Servus
 Manfred

pgsql-performance by date:

Previous
From: Manfred Koizar
Date:
Subject: Re: Why will vacuum not end?
Next
From: Josh Berkus
Date:
Subject: Re: Why will vacuum not end?