| From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
| Cc: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "Gregory Stark" <stark(at)enterprisedb(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Grouped Index Tuples / Clustered Indexes |
| Date: | 2007-03-11 19:56:48 |
| Message-ID: | 1173643008.3641.468.camel@silverbirch.site |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, 2007-03-11 at 19:06 +0100, Florian G. Pflug wrote:
> Heikki Linnakangas wrote:
> > There's a third related term in use as well. When you issue CLUSTER, the
> > table will be clustered on an index. And that index is then the "index
> > the table is clustered on". That's a bit cumbersome but that's the
> > terminology we're using at the moment. Maybe we should to come up with a
> > new term for that to avoid confusion..
>
> This reminds me of something i've been wondering about for quite some
> time. Why is it that one has to write "cluster <index> on <table>",
> and not "cluster <table> on <index>"?
>
> To me, the second variant would seem more logical, but then I'm
> not a native english speaker...
>
> I'm not suggesting that this should be changed, I'm just wondering
> why it is the way it is.
No idea, but I agree it conveys exactly the opposite view of what
happens when the command is issued.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2007-03-11 23:05:29 | Re: [HACKERS] COMMIT NOWAIT Performance Option (patch) |
| Previous Message | Simon Riggs | 2007-03-11 19:54:56 | Re: Grouped Index Tuples / Clustered Indexes |