Re: truncate/create slowness

From: "Julian Scarfe" <julian(at)avbrief(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-general(at)postgresql(dot)org>
Subject: Re: truncate/create slowness
Date: 2005-03-31 17:52:28
Message-ID: 01c801c5361a$68ea6ad0$0600a8c0@Wilbur
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> It's possible you could get out of this by vacuum full and then reindex
> each catalog, but it might be easier to dump and reload the database ...

I've got a similar issue, but caused by neglect rather than anything to to
with pg_autovacuum.

Do you have any rules of thumb for deciding when a pg_dumpall/restore is
likely to be faster than a vacuum full? Or perhaps more straightforwardly,
how would you expect the time required for a vacuum full to scale with pages
used and rows in the table?

Thanks

Julian Scarfe

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Robin M. 2005-03-31 18:14:18 Re: truncate/create slowness
Previous Message Joshua D. Drake 2005-03-31 17:44:07 Re: storing files in postgres