> If not, dump and restore the table.
Unfortunately we do not have adequate disk space, we wanted to reduce
the database size in order to back it up, cause there is no more space
for backups either 0_o
Is there any way to prevent
Dump & restore - you mean pg_dump?
---(en
On Tue, Aug 07, 2007 at 08:40:47AM -0700, Steve Atkins wrote:
> If you have adequate disk space free (enough to hold another
> copy of the new table) and the table has an index on it, then
> CLUSTER the table.
Be advised that there's some MVCC issues with CLUSTER in current
versions, but normally
"Steve Atkins" <[EMAIL PROTECTED]> writes:
> On Aug 7, 2007, at 1:17 AM, Sergei Shelukhin wrote:
>
>> Or any way to optimize it besides the obvious (maintenace_work_mem &
>> max_fsm_pages increases and no workload)?
>> Can someone please help with this one?
What does the output of "vacuum verbose
On Aug 7, 2007, at 1:17 AM, Sergei Shelukhin wrote:
Ok here's the update after ~30 hours we have killed vacuum full and
did vacuum on the tables we freed.
However, VACUUM hasn't freed any space at all 0_o
We want to launch vacuum full on per-table basis but we can't have any
more downtime right
Ok here's the update after ~30 hours we have killed vacuum full and
did vacuum on the tables we freed.
However, VACUUM hasn't freed any space at all 0_o
We want to launch vacuum full on per-table basis but we can't have any
more downtime right now so we will launch it at night today.
The original
Hi. We have archived and removed majority of data from a database, the
main impact was on 4 tables, which lost several million rows (3
tables) and several dozen million rows (one table).
Naturally we decided to execute VACUUM FULL on the database to reclaim
all the space; it keeps running for 22 h
