Pavel Stehule escribió: > 2009/10/27 Alvaro Herrera <alvherre@xxxxxxxxxxxxxxxxx>: > > JC Praud escribió: > > > >> So my question are: can the autovacuum daemon perform vacuum full ? Or > >> another internal postgres process ? Could it come from the TRUNCATE I run > >> and canceled 4 days before ? > > > > No. Autovacuum only issues commands that don't lock tables strongly. I > > doubt this has anything to do with your old TRUNCATE either. My guess > > is that somebody else ran TRUNCATE and forgot to tell you; or maybe an > > automatic external process (cron or some such). > > look again on code. I checked it today. When is possible to drop some > pages from end, then vacuum do lock, and try to remove free pages. I > checked it. This process is started from full vacuum, lazy vacuum and > autovacuum too. We have similar issue like JC has. Oh, the truncation bit. Yeah. It uses a conditional lock acquire though, so if the table is already locked it shouldn't try to do anything. Now 40 mins walking those pages to figure out that they need to be truncated, I concede that it's too much. Maybe we shouldn't be doing a backwards scan; perhaps this breaks the OS readahead and make it even slower. -- Alvaro Herrera http://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
