Re: pg_restore takes ages

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>, Vivek Khera <khera(at)kcilink(dot)com>, <pgsql-general(at)postgresql(dot)org>
Subject: Re: pg_restore takes ages
Date: 2003-10-03 23:50:27
Message-ID: Pine.LNX.4.33.0310031746280.28525-100000@css120.ihs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, 3 Oct 2003, scott.marlowe wrote:

> On Fri, 3 Oct 2003, Tom Lane wrote:
> >
> > It'd be interesting to think about whether a write-caching IDE drive
> > could safely be used for data storage, if WAL is elsewhere.
>
> Well, I just so happen to have a machine with two drives in it. I'll get
> back to you on that.

Ok, I just tested it. I put pg_xlog and pg_clog on a drive that was set
to write cache disabled, and left the data on a drive where caching was
enabled. The tps on a pgbench -c 5 -t 500 on the single drive was 45 to
55. With the pg_[xc]log moved to another drive and all, I got up to 108
tps. About double performance, as you'd expect. I didn't test the data
drive with write caching disabled, but my guess is it wouldn't be any
slower since pgsql doesn't wait on the rest.

I pulled the plug three times, and all three times the database came up in
recovery mode and sucessfully recovered. I didn't bother testing to see
if write caching would corrupt it as I'm pretty sure it would, it
certainly did when everything was on one drive.

Would you like to try some kind of wal patch out on it while I've got it
for testing? I'd be glad to torture that poor little box some more if
you're in the mood and the beta period is winding down. It's running 7.4
beta3, by the way.

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message David Wheeler 2003-10-04 00:21:22 ANNOUNCE: Bricolage 1.6.6
Previous Message Kathy Zhu 2003-10-03 23:32:22 Re: group by