Re: VACUUM process running for a long time

From: raghavendra t <raagavendra(dot)rao(at)gmail(dot)com>
To: Alan Hodgson <ahodgson(at)reinvent(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: VACUUM process running for a long time
Date: 2010-04-15 01:50:21
Message-ID: n2qbc7de5a31004141850u7c88945te6cd02edd033618@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi

> >
> > > You might consider partitioning this table by date, either by day or by
> > > week, and instead of deleting old rows, drop entire old partitions
> >
> > this is not really good workaround...

As a First choice, This is a very good workaround for your present
situation.

As a second choice, Setting the maintenance_work_mem will give a performance
boost but we can only increase the memory upto 2GB. This parameter Sets the
limit for the amount that autovacuum, manual vacuum, bulk index build and
other maintenance routines are permitted to use. Setting it to a moderately
high value will increase the efficiency of vacuum and other operations.

But i go with first choice..

Regards
Raghavendra

> >
> > > You might consider partitioning this table by date, either by day or by
> > > week, and instead of deleting old rows, drop entire old partitions
> >
> > this is not really good workaround...
>
> Actually it's a very good workaround, that a lot of people use for exactly
> this purpose. It's a lot less disk I/O than delete+vacuum even when you're
> not experiencing bloat.
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Bruce Momjian 2010-04-15 02:53:41 Re: pl/java status
Previous Message Bruce Momjian 2010-04-15 01:40:17 Rogue TODO list created