| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Shridhar Daithankar <ghodechhap(at)ghodechhap(dot)net> |
| Cc: | grupos(at)carvalhaes(dot)net, pgsql-general(at)postgresql(dot)org, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: [PERFORM] pg_restore taking 4 hours! |
| Date: | 2004-12-01 15:38:37 |
| Message-ID: | 8361.1101915517@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general pgsql-performance |
Shridhar Daithankar <ghodechhap(at)ghodechhap(dot)net> 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | George Woodring | 2004-12-01 16:44:16 | Variable column name in plpgsql function |
| Previous Message | Tom Lane | 2004-12-01 15:25:36 | Re: [HACKERS] Adding Reply-To: <listname> to Lists configuration ... |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Brian Hirt | 2004-12-01 16:46:43 | query with timestamp not using index |
| Previous Message | Riccardo G. Facchini | 2004-12-01 15:19:17 | Re: [PERFORM] pg_restore taking 4 hours! |