On Wed, Jun 18, 2008 at 9:26 AM, Decibel! <[EMAIL PROTECTED]> wrote:
> On Jun 17, 2008, at 11:37 AM, Scott Ribe wrote:
>
>> BOOM! Deadlock.
>>>
>>
>> No more likely than with the current cluster command. Acquiring the lock
>> is
>> the same risk; but it is held for much less time.
>>
>
>
> Actuall
On Jun 17, 2008, at 11:37 AM, Scott Ribe wrote:
BOOM! Deadlock.
No more likely than with the current cluster command. Acquiring the
lock is
the same risk; but it is held for much less time.
Actually, no (at least in 8.2). CLUSTER grabs an exclusive lock
before it does any work meaning t
> BOOM! Deadlock.
No more likely than with the current cluster command. Acquiring the lock is
the same risk; but it is held for much less time.
> ...I think what makes a lot
> more sense is to have a form of clustering that puts effort into
> placing tuples in the correct location.
Agreed that w
On May 28, 2008, at 11:21 AM, Scott Ribe wrote:
If I'm not totally off-base, here's one way to enable clustering on
systems
that run 24/7:
1 cluster current rows
1.1 note current last committed transaction
1.2 copy all visible rows to new table in cluster order
1.3 build indexes on
