Re: remove flatfiles.c - Mailing list pgsql-hackers

From Robert Haas
Subject Re: remove flatfiles.c
Date
Msg-id 603c8f070909021210l3d0ede5fg6ae0ebd9a44b9f5c@mail.gmail.com
Whole thread Raw
In response to Re: remove flatfiles.c  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: remove flatfiles.c
List pgsql-hackers
On Wed, Sep 2, 2009 at 2:54 PM, Tom Lane<tgl@sss.pgh.pa.us> wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> So I have a script that goes and finds bloated tables and runs VACUUM
>> FULL on them in the middle of the night if the bloat passes a certain
>> threshold.  The tables are small enough and the number of users is low
>> enough that this doesn't cause any problems for me.  I'm OK if the
>> name of the command changes, but I'd like there to be a command that I
>> can pass a table name to and get my table debloated without having to
>> make any follow-on decisions (such as picking an index to cluster by).
>
> I think we *should* have a command that works like CLUSTER except it just
> seqscans the source table without depending on any particular index.
> Whether it's called VACUUM FULL or something else is a detail.

Yeah.  We could do this by extending the syntax for cluster (e.g.
CLUSTER [VERBOSE] tablename [USING indexname | WITH NO INDEX]), but
I'm not sure whether that has any real advantage over just using the
existing command name.

I confess to being a little fuzzy on the details of how this
implementation (seq-scanning the source table for live tuples) is
different/better from the current VACUUM FULL implementation.  Can
someone fill me in?

...Robert


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Derived files that are shipped in the distribution used to be
Next
From: Robert Haas
Date:
Subject: Re: c function: keep objects in memory for all session or all transaction