| From: | "Guillaume Smet" <guillaume(dot)smet(at)gmail(dot)com> |
|---|---|
| To: | Decibel! <decibel(at)decibel(dot)org> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: First steps with 8.3 and autovacuum launcher |
| Date: | 2007-09-19 07:08:58 |
| Message-ID: | 1d4e0c10709190008i1e222eedgf800c73d808e7e85@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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,
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.
--
Guillaume
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2007-09-19 07:15:43 | Dynamically adding index types (was GIT indexes) |
| Previous Message | Joshua D. Drake | 2007-09-19 03:41:18 | Re: Open issues for HOT patch |