> 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
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
> > * pren
* 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
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 VAC
> 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
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 inheritanc
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.
