James Rogers <jamesr@best.com> writes:
> On 10/2/03 11:34 PM, "Hannu Krosing" <hannu@tm.ee> wrote:
> >
> > What I actually thought I was describing is how CLUSTER should work in a
> > postgres flavour of MVCC storage ;). Not the CLUSTER command, but the
> > whole feature.
>
>
> Yeah, I can see this. "Clustering" doesn't really imply ordering, just
> tuple proximity in the heap.
So I'm a bit confused about the term "Clustering". It seems Postgres uses it
to mean simply ordering the tuple storage within an otherwise normal table.
However in other databases it seems to mean something more complex. I've never
used it in Oracle, but from what I read it seems Oracle thinks "clustering"
means storing the tuples for one table in the heap for *another* table
entirely.
The typical usage scenario envisioned is to store the tuples for child records
near the parent record in a related table. Ie, say you have a users table with
an ACL list, each user has possibly many ACL entries on the ACL list. You
could cluster the ACL entry list onto the users table so that the entries for
a given user would be stored *in the users table heap* near the record for
that user.
I've never seen anyone use this feature, and I never seriously considered it
myself. It sort of has the feel of an antiquated feature that traded too much
flexibility and abstraction for raw performance on very slow disk hardware.
However I wonder if the "nested tables" feature doesn't use it under the hood
though. It seems they would both be useful for the same types of tables.
I'm not sure what this means for Postgres. I'm not sure if Postgres should use
a different name to avoid confusion and possibly to leave room in the future
for the possibility of supporting something like this. Or perhaps something
like this would be useful for Postgres now or in the near future? Or perhaps
the consensus is as I said, that this is an old idea that no longer gets any
respect and postgres should just pretend it doesn't exist?
--
greg