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
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 |