On Sep 19, 2007, at 2:08 AM, Guillaume Smet wrote:
> On 9/19/07, Decibel! <decibel@decibel.org> wrote:
>> Odd... I'd expect it to actually be beneficial to run analyze on a
>> table
>> at roughly the same time as PK building, because you'd make better
>> use
>> of cache.
>
> Sure if your database fits entirely in RAM (otherwise if two big
> tables are analyzed while we create the primary key for a third one,
You missed my point... what we'd want to happen is for the analyze to
take place while that table had a good chance of still being in memory.
> it won't help us at all). And even in this case, it's not sure the
> time lost by waiting the lock is worth it. It could for sure if the
> restore could create the other primary keys while waiting for the lock
> on the analyzed tables, which is obviously not the case.
> In my particular case, the restore stales a lot of times with status
> ALTER TABLE waiting.
It might be worth looking into creating a different lock for ALTERs
that actually change database page layout vs ALTERs that don't, since
there's no reason you couldn't run ANALYZE while adding a PK (for
example).
--
Decibel!, aka Jim C. Nasby, Database Architect decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828
