Re: auto truncate/vacuum full - Mailing list pgsql-general

From Alvaro Herrera
Subject Re: auto truncate/vacuum full
Date
Msg-id 20091027193958.GJ4876@alvh.no-ip.org
Whole thread Raw
In response to Re: auto truncate/vacuum full  (Pavel Stehule <pavel.stehule@gmail.com>)
Responses Re: auto truncate/vacuum full
Re: auto truncate/vacuum full
List pgsql-general
Pavel Stehule escribió:
> 2009/10/27 Alvaro Herrera <alvherre@commandprompt.com>:
> > 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.

pgsql-general by date:

Previous
From: VladK
Date:
Subject: PHP + PDO + PGPOOL = Segmentation fault
Next
From: Richard Huxton
Date:
Subject: Re: PHP + PDO + PGPOOL = Segmentation fault