Re: clustering without locking - Mailing list pgsql-general

From Tom Lane
Subject Re: clustering without locking
Date
Msg-id 29002.1209775295@sss.pgh.pa.us
Whole thread Raw
In response to Re: clustering without locking  (Craig Ringer <craig@postnewspapers.com.au>)
Responses Re: clustering without locking  (Craig Ringer <craig@postnewspapers.com.au>)
List pgsql-general
Craig Ringer <craig@postnewspapers.com.au> writes:
> So ... is this crazy? Concurrently clustering the table by moving each
> record *twice*, in batches, with pauses to allow old versions to cease
> being visible by any live transaction? Or can it actually work?

It seems to me you'd have a pretty horrid bloat problem: at completion,
the table and all its indexes must be at least twice the minimum size,
and it's unlikely that you'd be able to compact them much afterward.
(If any other insertions were in progress they'd have probably ended up
near the end of the enlarged table, so just truncating is unlikely to
work for the table --- and for the indexes it's a lost cause entirely.)

Now admittedly this is no worse than what you get after a full-table
UPDATE, but for a maintenance operation that is supposed to be improving
efficiency, it doesn't seem like a pleasant property.

            regards, tom lane

pgsql-general by date:

Previous
From: Craig Ringer
Date:
Subject: Re: clustering without locking
Next
From: Craig Ringer
Date:
Subject: Re: clustering without locking