Re: Why will vacuum not end?

From: Manfred Koizar <mkoi-pg(at)aon(dot)at>
To: "Shea,Dan [CIS]" <Dan(dot)Shea(at)ec(dot)gc(dot)ca>
Cc: 'Josh Berkus' <josh(at)agliodbs(dot)com>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Why will vacuum not end?
Date: 2004-04-25 00:28:37
Message-ID: l40m80ta1765qtiif17lj0uh1039ii4kdv@email.aon.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Sat, 24 Apr 2004 15:58:08 -0400, "Shea,Dan [CIS]" <Dan(dot)Shea(at)ec(dot)gc(dot)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

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Josh Berkus 2004-04-25 01:49:07 Re: Why will vacuum not end?
Previous Message Manfred Koizar 2004-04-25 00:05:22 Re: Why will vacuum not end?