| From: | Scott Carey <scott(at)richrelevance(dot)com> |
|---|---|
| To: | Justin Pitts <justinpitts(at)gmail(dot)com> |
| Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>, Ibrahim Harrani <ibrahim(dot)harrani(at)gmail(dot)com>, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
| Subject: | Re: cluster index on a table |
| Date: | 2009-07-16 18:21:46 |
| Message-ID: | C684BDCA.A3FF%scott@richrelevance.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
I could be wrong, but I think MSSQL only keeps the data specified in the
index in the index, and the remaining columns in the data.
That is, if there is a clustered index on a table on three columns out of
five, those three columns in the index are stored in the index, while the
other two are in a data portion. But it has been several years since I
worked with that DB.
They are certainly storing at least those columns in the index itself. And
that feature does work very well from a performance perspective.
IOT in Oracle is a huge win in some cases, but a bit more clunky for others
than Clustered Indexes in MSSQL. Both are highly useful.
On 7/16/09 10:52 AM, "Justin Pitts" <justinpitts(at)gmail(dot)com> wrote:
> ISTR that is the approach that MSSQL follows.
>
>>
>> Storing the full tuple in an index and not even having a data only
>> page
>> would also be an interesting approach to this (and perhaps simpler
>> than a
>> separate index file and data file if trying to keep the data in the
>> order of
>> the index).
>
>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2009-07-16 18:30:56 | Re: [PERFORM] Incr/Decr Integer |
| Previous Message | William Scott Jordan | 2009-07-16 17:56:47 | Incr/Decr Integer |