| From: | Greg Stark <gsstark(at)mit(dot)edu> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | "J(dot) Andrew Rogers" <jrogers(at)neopolitan(dot)com>, Magnus Hagander <mha(at)sollentuna(dot)net>, pgsql-performance(at)postgresql(dot)org, mischa(dot)sandberg(at)telus(dot)net |
| Subject: | Re: Equivalent praxis to CLUSTERED INDEX? |
| Date: | 2004-08-27 03:39:42 |
| Message-ID: | 87pt5dnta9.fsf@stark.xeocode.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> Updated TODO item:
>
> o Automatically maintain clustering on a table
>
> This would require some background daemon to maintain clustering
> during periods of low usage. It might also require tables to be only
> paritally filled for easier reorganization. It also might require
> creating a merged heap/index data file so an index lookup would
> automatically access the heap data too.
Fwiw, I would say the first "would" is also a "might". None of the previous
discussions here presumed a maintenance daemon. The discussions before talked
about a mechanism to try to place new tuples as close as possible to the
proper index position.
I would also suggest making some distinction between a cluster system similar
to what we have now but improved to maintain the clustering continuously, and
an actual index-organized-table where the tuples are actually only stored in a
btree structure.
They're two different approaches to similar problems. But they might both be
useful to have, and have markedly different implementation details.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2004-08-27 04:35:07 | Re: Equivalent praxis to CLUSTERED INDEX? |
| Previous Message | Bruce Momjian | 2004-08-27 01:45:50 | Re: Equivalent praxis to CLUSTERED INDEX? |