Re: First steps with 8.3 and autovacuum launcher

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

In response to

Responses

Browse pgsql-hackers by date

  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)