Re: Vacuum full crash

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Mikko Partio" <mpartio(at)gmail(dot)com>
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: Vacuum full crash
Date: 2008-03-30 19:28:25
Message-ID: 27266.1206905305@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

"Mikko Partio" <mpartio(at)gmail(dot)com> writes:
> Interesting. What is planned substitute for VACUUM FULL? CLUSTER?

What's been discussed is something that works roughly like CLUSTER
but doesn't bother to sort the data any particular way (ie, just do
a seqscan not an indexscan in the data-copying phase). This would
certainly dominate VACUUM FULL in contexts where you've removed a
large fraction of the rows. In cases where you haven't, the large
transient space requirement (2x the table size) would be objectionable,
but it's not real clear why you need a VACUUM FULL rather than plain
VACUUM in such cases anyway.

A lot of the context for this arises from recent and planned
improvements, notably

(1) CLUSTER is MVCC-safe now, removing one of the core arguments
for not using it for routine cleanup.

(2) Planned fixes like the dead space map will substantially
reduce the cost of running frequent plain vacuums. That together
with autovacuum (which we could make more aggressive in consequence)
should help to avoid getting into situations where VACUUM FULL is
needed in the first place.

We certainly couldn't have considered eliminating VACUUM FULL before
this, but it's starting to seem a viable option to me.

regards, tom lane

In response to

Browse pgsql-admin by date

  From Date Subject
Next Message Tom Lane 2008-03-30 19:32:35 Re: local authentication with md5
Previous Message Bernhard D Rohrer 2008-03-30 19:24:04 Re: local authentication with md5 - solved