Re: pg_restore takes ages
От | scott.marlowe |
---|---|
Тема | Re: pg_restore takes ages |
Дата | |
Msg-id | Pine.LNX.4.33.0310031746280.28525-100000@css120.ihs.com обсуждение исходный текст |
Ответ на | Re: pg_restore takes ages ("scott.marlowe" <scott.marlowe@ihs.com>) |
Ответы |
Re: pg_restore takes ages
|
Список | 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.
В списке pgsql-general по дате отправления: