James Rogers <[EMAIL PROTECTED]> writes: > On 10/2/03 11:34 PM, "Hannu Krosing" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly