Re: [PERFORM] pg_restore taking 4 hours!

От: Tom Lane
Тема: Re: [PERFORM] pg_restore taking 4 hours!
Дата: ,
Msg-id: 8361.1101915517@sss.pgh.pa.us
(см: обсуждение, исходный текст)
Ответ на: Re: [PERFORM] pg_restore taking 4 hours!  (Shridhar Daithankar)
Список: pgsql-general

Скрыть дерево обсуждения

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 по дате сообщения:

От: Joachim Zobel
Дата:
Сообщение: createlang plperl fails with 8.0 beta5
От: Thomas F.O'Connell
Дата:
Сообщение: Poor Performance with Distinct Subqueries with EXISTS and EXCEPT