| From: | Hannu Krosing <hannu(at)skype(dot)net> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Neil Conway <neilc(at)samurai(dot)com>, pgsql-patches(at)postgresql(dot)org |
| Subject: | Re: PATCH to allow concurrent VACUUMs to not lock each |
| Date: | 2005-05-23 16:20:16 |
| Message-ID: | 1116865216.4849.24.camel@fuji.krosing.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers pgsql-patches |
On E, 2005-05-23 at 11:42 -0400, Tom Lane wrote:
> Hannu Krosing <hannu(at)skype(dot)net> writes:
> > I can't think of any other cases where it could matter, as at least the
> > work done inside vacuum_rel() itself seema non-rollbackable.
>
> VACUUM FULL's tuple-moving is definitely roll-back-able, so it might be
> prudent to only do this for lazy VACUUM. But on the other hand, VACUUM
> FULL holds an exclusive lock on the table so no one else is going to see
> its effects concurrently anyway.
I'm not interested in VACUUM FULL at all. This is improvement mainly for
heavy update OLAP databases, where I would not even think of running
VACUUM FULL.
I'll cheks if there's an easy way to exclude VACUUM FULL.
> As I said, it needs more thought than I've been able to spare for it yet
> ...
Ok, thanks for comments this far .
--
Hannu Krosing <hannu(at)skype(dot)net>
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2005-05-23 16:31:35 | Speeding up the Postgres lexer |
| Previous Message | Stef | 2005-05-23 16:16:03 | Obtaining Firing Statement clause in (pl/perlu) Trigger Function |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bruce Momjian | 2005-05-23 17:13:47 | Remove unnecessary parentheses |
| Previous Message | Tom Lane | 2005-05-23 15:42:31 | Re: PATCH to allow concurrent VACUUMs to not lock each |