From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Greg Stark <gsstark(at)mit(dot)edu> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Index/Function organized table layout |
Date: | 2003-10-05 10:10:06 |
Message-ID: | 1065348605.16274.15.camel@fuji.krosing.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Greg Stark kirjutas P, 05.10.2003 kell 00:17:
> 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.
Read "A Conversation with Jim Gray" referenced from this slashdot
article:
http://slashdot.org/article.pl?sid=03/09/17/1246255&mode=thread&tid=126
for info on how disk drives are slower than ever (relatively), and how
one should treat them as such, especially for large data volumes.
> 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?
We can't pretend CLUSTER does not exist until we have some better
technology to offer instead.
------------
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Meskes | 2003-10-05 11:06:41 | Day of week question |
Previous Message | Hans-Jürgen Schönig | 2003-10-05 09:21:03 | Re: 2-phase commit |