From: | "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | "John Huttley" <John(at)mib-infotech(dot)co(dot)nz> |
Cc: | "Andrew Sullivan" <ajs(at)commandprompt(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Slow updates, poor IO |
Date: | 2008-09-27 15:09:09 |
Message-ID: | dcc563d10809270809g17938b7fvf28a3624028e0f3b@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Fri, Sep 26, 2008 at 5:03 PM, John Huttley <John(at)mib-infotech(dot)co(dot)nz> wrote:
> Hi Andrew,
> There are two problems.
> The first is the that if there is a table with a index and an update is
> performed on a non indexed field,
> the index is still re indexed.
I assume you mean updated, not reindexed, as reindexed has a different
meaning as regards postgresql. Also, this is no longer true as of
version 8.3. If you're updating non-indexed fields a lot and you're
not running 8.3 you are doing yourself a huge disservice.
>this is part of the trade-offs of MVCC.
was... was a part of the trade-offs.
> We should reasonably expect that the total amount of IO will go up, over a
> non-indexed table.
>
> The second thing is that the disk IO throughput goes way down.
>
> This is not an issue with MVCC, as such, except that it exposes the effect
> of a write to an indexed field.
It's really an effect of parallel updates / writes / accesses, and is
always an issue for a database running on a poor storage subsystem. A
db with a two drive mirror set is always going to be at a disadvantage
to one running on a dozen or so drives in a RAID-10
From | Date | Subject | |
---|---|---|---|
Next Message | John Huttley | 2008-09-27 22:33:56 | Re: Slow updates, poor IO |
Previous Message | Greg Smith | 2008-09-27 07:04:08 | Re: Slow updates, poor IO |