dump/load - Mailing list pgsql-hackers

From Chris Albertson
Subject dump/load
Date
Msg-id 358173C7.739BEEC8@topdog.logicon.com
Whole thread Raw
List pgsql-hackers
Bruce Momjian wrote:
>
> > I have no problem with catalog changes and dumping the schema if we can
> > write a script to help them do it. I would hope we can avoid having to
> > make
> > someone dump and reload their own data. I am thinking that it could be
> > pretty inconvenient to dump/load and reindex something like a 50GB table
> > with
> > 6 indexes.

1) It did take me about 14 hours to reload a dumpped database last
week.  I have a Sun Ultra with UW SCSI disks,  (no fsync big buffer
cache and all)  I have about 16M rows overall. By end of year I
could have 100M rows.

2) If you can fix Postgres so that it _could_ in fact handle a 50GB
table I would be very happy to reload even 100M rows.  My current
database has tables called "tablename_001, tablename_002,
tablename_003 and so on, all <2GB slices of what should go into one
larger table.

I said a few weeks ago that I would report on performence of a
Pent. 200 with IDE vs. a Sun Ultra with UW SCSI.  Here is an
observation.  Both PC and Sun had same data and software.

While index building on the Linux PC it is CPU bound.  Top shows
my 200Mhz non-MMX pentium maxed out near 85%

On the Sun (Solaris) the process is I/O bound. Even with the much
faster disk.

It apears that UW SCSI disks are about double the speed of
IDE while a 200Mhz Ultra SPARC CPU is maybe five or six
times faster then a 200Mhz Pentium.  Overall database operations
are two to four times faster on the Sun.

Conclusions:  1) the Sun's CPU power is overkill.  We could do
with a dual CPU Pentium. II 400Mhz system, 256MB RAM and save
some $$.  2) UW SCSI disks are not all that fast.  What is needed
is a hardware RAID box with N-way disk striping.
--

--
--Chris Albertson

  chris@topdog.logicon.com                Voice:  626-351-0089  X127
  Logicon RDA, Pasadena California          Fax:  626-351-0699

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] S_LOCK reduced contention
Next
From: "Henry B. Hotz"
Date:
Subject: RE: [HACKERS] inlining