Ian Harding [EMAIL PROTECTED] writes:
Tom Lane wrote:
The CLUSTER implementation is so shoddy at the moment that I'm hesitant
to encourage people to use it anyway :-(. We've got to rewrite it so
that it doesn't drop other indexes, lose constraints, break foreign
key and inheritance
Also, in our case, clustering by a single index is not really sufficient.
Within a single bill we would like to cluster the items by service. I was
thinking or writing a program that would do a pg_dump, order by columns as
requested and then dump it back in. I would've done it except that
Added to TODO (part of this is reorganization of cluster items):
* CLUSTER
* cluster all tables at once
* prent lose of constraints, indexes, permissions, inheritance
* Automatically keep clustering on a table
* Keep statistics about clustering, perhaps during
* Bruce Momjian [EMAIL PROTECTED] [010111 13:12] wrote:
Added to TODO (part of this is reorganization of cluster items):
* CLUSTER
* cluster all tables at once
* prent lose of constraints, indexes, permissions, inheritance
* Automatically keep clustering on a table
We have talked about this, but we have not seen enought corruption cases
to warrant it.
* Bruce Momjian [EMAIL PROTECTED] [010111 13:12] wrote:
Added to TODO (part of this is reorganization of cluster items):
* CLUSTER
* cluster all tables at once
* prent lose of
We have talked about this, but we have not seen enought
corruption cases to warrant it.
Huh?! Just pg_ctl -m immediate stop in = 7.0.X with high
insert activity and ... pray.
It's changed in 7.1 by WAL - btree doesn't lose tuples in split
ops anymore and in after crash restart you'll never
On Tue, Jan 09, 2001 at 10:51:35AM -0500, Bruce Momjian wrote:
Well, clustering certainly speeds up index access to multiple heap
values because duplicate values are all on the same heap page. One
thing that is missing is that there is no preference for index scans for
clustered indexes.
