Re: Postgres on RAID5

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Arshavir Grigorian <ag(at)m-cam(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Postgres on RAID5
Date: 2005-03-11 22:37:10
Message-ID: 5897.1110580630@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Arshavir Grigorian <ag(at)m-cam(dot)com> writes:
> Tom Lane wrote:
>> How are you measuring that write rate (seeing that pg_restore doesn't
>> provide any such info)?

> Well, if the restore is going on for X number of hours and you have Y
> records loaded, it's not hard to ballpark.

Yeah, but how do you know that you have Y records loaded?

What I'm trying to get at is what the restore is actually spending its
time on. It seems unlikely that a COPY per se would run that slowly;
far more likely that the expense is involved with index construction
or foreign key verification. You could possibly determine what's what
by watching the backend process with "ps" to see what statement type
it's executing most of the time.

BTW, is this a full database restore (schema + data), or are you trying
to load data into pre-existing tables? The latter is generally a whole
lot slower because both index updates and foreign key checks have to be
done retail instead of wholesale. There are various ways of working
around that but you have to be aware of what you're doing.

Also, if it is indexing that's eating the time, boosting the sort_mem
setting for the server would help a lot.

regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Arshavir Grigorian 2005-03-12 00:22:56 Re: Postgres on RAID5
Previous Message Alvaro Herrera 2005-03-11 22:36:46 Re: Postgres on RAID5