Skip site navigation (1) Skip section navigation (2)

Re: Slow updates, poor IO

From: "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>
To: "John Huttley" <John(at)mib-infotech(dot)co(dot)nz>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Slow updates, poor IO
Date: 2008-09-27 22:54:20
Message-ID: dcc563d10809271554wd20049ch5fee8f02b8a06d34@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Sat, Sep 27, 2008 at 4:33 PM, John Huttley <John(at)mib-infotech(dot)co(dot)nz> wrote:
>
> > > this is part of the trade-offs of MVCC.
>
> > was...  was a part of the trade-offs.
>
> You are thinking of HOT?
> I don't think it applies in the case of full table updates??

Sure, you just need a table with plenty of empty space in it, either
from vacuumed previous deletes / inserts or with a low fill factor
like 50%.

> 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
>
> Oh well, I'm forever going to be disadvantaged.

Why?  A decent caching raid controller and a set of 4 to 8 SATA drives
can make a world of difference and the cost is not that high for the
gain in performance.  Even going to 4 drives in a software RAID-10 can
make a lot of difference in these situations, and that can be done
with spare machines and hard drives.

In response to

pgsql-performance by date

Next:From: Tom LaneDate: 2008-09-28 14:33:08
Subject: Re: Slow updates, poor IO
Previous:From: John HuttleyDate: 2008-09-27 22:33:56
Subject: Re: Slow updates, poor IO

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group