Re: remove flatfiles.c

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: remove flatfiles.c
Дата
Msg-id 603c8f070909021210l3d0ede5fg6ae0ebd9a44b9f5c@mail.gmail.com
обсуждение исходный текст
Ответ на Re: remove flatfiles.c  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: remove flatfiles.c  (Greg Stark <gsstark@mit.edu>)
Список 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 по дате отправления:

Предыдущее
От: Magnus Hagander
Дата:
Сообщение: Re: Re: [COMMITTERS] pgsql: Derived files that are shipped in the distribution used to be
Следующее
От: Robert Haas
Дата:
Сообщение: Re: c function: keep objects in memory for all session or all transaction