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
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? |