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
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 or slow,
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, 14350 are
-
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 verbose pg_class;
INFO: vacuuming
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
unsubscribe pgsql-general
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
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 the
