Re: First steps with 8.3 and autovacuum launcher
От | Decibel! |
---|---|
Тема | Re: First steps with 8.3 and autovacuum launcher |
Дата | |
Msg-id | 83E05AF9-9085-477D-947A-EF23D89E183F@decibel.org обсуждение исходный текст |
Ответ на | Re: First steps with 8.3 and autovacuum launcher ("Guillaume Smet" <guillaume.smet@gmail.com>) |
Ответы |
Re: First steps with 8.3 and autovacuum launcher
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: