| From: | Greg Stark <gsstark(at)mit(dot)edu> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Jaime Casanova <jaime(at)2ndquadrant(dot)com>, Gabriele Bartolini <gabriele(dot)bartolini(at)2ndquadrant(dot)it>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Proposed patch: Smooth replication during VACUUM FULL |
| Date: | 2011-05-02 15:50:48 |
| Message-ID: | BANLkTi=WyPVEG3Gt90h9q+5VLn94DX-CKA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, May 2, 2011 at 3:37 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> As for "copious technical evidence", I saw no evidence provided
> whatsoever that this patch really did anything much to fix the
> reported problem. Yeah, it would help during the initial scan
> of the old rel, but not during the sort or reindex steps.
>
Well if Simon's right that it's a question of generating an
overwhelming amount of wal rather than saturating the local i/o then
the sort isn't relevant. I'm not sure of what the scale of wal from
the reindex operation is compared to the table rebuild.
Of course you would have same problem doing a COPY load or even just
doing a sequential scan of a recently loaded table. Or is there
something about table rebuilds that is particularly nasty?
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2011-05-02 16:09:54 | Re: Bad COMPACT_ALLOC_CHUNK size in tsearch/spell.c? |
| Previous Message | Alvaro Herrera | 2011-05-02 15:15:09 | Re: HTML tags :/ |