"Julian Scarfe" <[EMAIL PROTECTED]> writes:
> 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 t
unsubscribe pgsql-general
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
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_dum
al Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of Tom Lane
Sent: jeudi 31 mars 2005 17:17
To: Joe Maldonado
Cc: pgsql-general@postgresql.org
Subject: Re: [GENERAL] truncate/create slowness
Joe Maldonado <[EMAIL PROTECTED]> writes:
> db=# vacuum analyze verbo
Joe Maldonado <[EMAIL PROTECTED]> writes:
> db=# vacuum analyze verbose pg_class;
> INFO: vacuuming "pg_catalog.pg_class"
> INFO: index "pg_class_oid_index" now contains 1404 row versions in
> 14486 pages
> DETAIL: 443 index row versions were removed.
> 14362 index pages have been deleted, 1435
"Joe Maldonado" <[EMAIL PROTECTED]> writes
> I suspect that pg_class has too many pages (49182 as below) and for
> some reason the above commands spend a lot of time updating it.
> vacuum/analyze on pg_class has not helped. Also, since the time taken
> for these commands is not consistently fast o
Hello all,
I frequently find that TRUNCATE table and CREATE or REPLACE FUNCTION
are both very slow taking 50 secs or more to complete. We have to run
both commands every minute, so this makes our application
non-functional. But it is not a slow deterioration over time.
Sometimes they run under a se
