| 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: | Whole Thread | Raw Message | 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 |