Postgres Professional
   

Re: [PERFORM] pg_restore taking 4 hours!

From: Tom Lane
Subject: Re: [PERFORM] pg_restore taking 4 hours!
Date: ,
Msg-id: 8361.1101915517@sss.pgh.pa.us
(view: Whole thread, Raw)
In response to: Re: [PERFORM] pg_restore taking 4 hours!  (Shridhar Daithankar)
List: pgsql-general

Tree view

pg_restore taking 4 hours!  (Rodrigo Carvalhaes, )
 Re: [PERFORM] pg_restore taking 4 hours!  (Shridhar Daithankar, )
  Re: [PERFORM] pg_restore taking 4 hours!  ("Riccardo G. Facchini", )
  Re: [PERFORM] pg_restore taking 4 hours!  (Tom Lane, )
 Re: [PERFORM] pg_restore taking 4 hours!  (Josh Berkus, )
 Re: pg_restore taking 4 hours!  (Thierry Missimilly, )
  Re: pg_restore taking 4 hours!  ("Joshua D. Drake", ) 
Shridhar Daithankar <> writes:
> On Wednesday 01 Dec 2004 4:46 pm, Rodrigo Carvalhaes wrote:
>> I need to find a solution for this because I am convincing customers
>> that are using SQL Server, DB2 and Oracle to change to PostgreSQL but
>> this customers have databases of 5GB!!! I am thinking that even with a
>> better server, the restore will take 2 days!

> Can you try bumping sort mem lot higher(basically whatever the machine can
> afford) so that index creation is faster?

It would be a good idea to bump up vacuum_mem as well.  In current
sources it's vacuum_mem (well actually maintenance_work_mem) that
determines the speed of CREATE INDEX; I forget just how long that
behavior has been around, but 7.4.6 might do it too.

            regards, tom lane

pgsql-general by date:

Previous:
From: Joachim Zobel
Date:
Subject: createlang plperl fails with 8.0 beta5
Next:
From: Thomas F.O'Connell
Date:
Subject: Poor Performance with Distinct Subqueries with EXISTS and EXCEPT