Re: auto truncate/vacuum full

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
Cc: JC Praud <brutaltruth42(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: auto truncate/vacuum full
Date: 2009-10-27 19:39:58
Message-ID: 20091027193958.GJ4876@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Pavel Stehule escribió:
> 2009/10/27 Alvaro Herrera <alvherre(at)commandprompt(dot)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.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Richard Huxton 2009-10-27 19:43:32 Re: PHP + PDO + PGPOOL = Segmentation fault
Previous Message Pavel Stehule 2009-10-27 19:02:18 Re: auto truncate/vacuum full