Re: CLUSTER all tables at once?

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)atentus(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: CLUSTER all tables at once?
Date: 2002-08-14 05:45:45
Message-ID: 200208140545.g7E5jjp02681@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Alvaro Herrera <alvherre(at)atentus(dot)com> writes:
> > Maybe if some index had the indisclustered bit set one could select
> > that; but is it possible for some table to have more than one index with
> > it? Intuition (but no code observation) says no.
>
> At the moment that bit will never be set at all, unless you were to
> reach in and set it with a manual "UPDATE pg_index" command.
>
> It would probably be feasible for the CLUSTER code to update the system
> catalogs to set the bit on the index used for the clustering (and clear
> it from any others it might be set on). Then indisclustered would have
> the semantics of "the index most recently used in CLUSTERing its table",
> which seems pretty reasonable. And it'd fit in nicely as the control
> bit for an auto-CLUSTER command.

Added to TODO:

o Cluster all tables at once using pg_index.indisclustered or primary
key

> > And what happens with those tables that do not have any such index?
>
> Nothing, would be my vote. You'd just re-CLUSTER all tables that have
> been clustered before, the same way they were last clustered.
>
> (I'm not actually convinced that this behavior is worth the code space
> it'd take to implement, btw.)

I was thinking of a shell script for this, not something in the backend.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2002-08-14 05:49:06 Re: FUNC_MAX_ARGS benchmarks
Previous Message Tom Lane 2002-08-14 05:44:05 Re: Better handling of parse errors