From: | Decibel! <decibel(at)decibel(dot)org> |
---|---|
To: | Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: First steps with 8.3 and autovacuum launcher |
Date: | 2007-09-19 14:53:29 |
Message-ID: | 83E05AF9-9085-477D-947A-EF23D89E183F@decibel.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sep 19, 2007, at 2:08 AM, Guillaume Smet wrote:
> On 9/19/07, Decibel! <decibel(at)decibel(dot)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(at)decibel(dot)org
Give your computer some brain candy! www.distributed.net Team #1828
From | Date | Subject | |
---|---|---|---|
Next Message | Guillaume Smet | 2007-09-19 15:00:24 | Re: like/ilike improvements |
Previous Message | Tom Lane | 2007-09-19 14:37:30 | Re: Dynamically adding index types (was GIT indexes) |