Re: truncate/create slowness - Mailing list pgsql-general

From Julian Scarfe
Subject Re: truncate/create slowness
Date
Msg-id 01c801c5361a$68ea6ad0$0600a8c0@Wilbur
Whole thread Raw
In response to truncate/create slowness  (Joe Maldonado <jmaldonado@webehosting.biz>)
Responses Re: truncate/create slowness  ("Robin M." <robin@primus.ca>)
Re: truncate/create slowness  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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



pgsql-general by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Re: storing files in postgres
Next
From: "Robin M."
Date:
Subject: Re: truncate/create slowness