From: | Jim Nasby <jnasby(at)pervasive(dot)com> |
---|---|
To: | Todd A(dot) Cook <tcook(at)blackducksoftware(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ruairi <rcarroll(at)bluemetrix(dot)com>, pgsql-admin(at)postgresql(dot)org |
Subject: | Re: Restore of pg_dump taking a long time... |
Date: | 2006-05-25 20:51:54 |
Message-ID: | 6D7A0D55-3364-4733-B721-90BDC0D252C6@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On May 24, 2006, at 2:56 PM, Todd A. Cook wrote:
> Tom Lane wrote:
>> "Todd A. Cook" <tcook(at)blackducksoftware(dot)com> writes:
>>> I have found that increasing maintenance_work_mem can decrease index
>>> build speed on large tables:
>> You should probably re-measure when 8.2 comes out; we've fixed a
>> number
>> of performance issues in the sorting code that might cause that.
>
> Thanks. I'll do that. If I can, I'll try it sooner on a build
> from CVS.
If you'll be messing around with CVS, you might also want to try this
patch: http://jim.nasby.net/misc/pgsqlcompression/compress-sort.patch
(which was written by someone else). It hacks compression into the on-
disk sort code, which has shown a 50% speed improvement on my
machine. It should be fine to use for loading a database, but you
wouldn't want to leave it in for serious use (IIRC there's some cases
it flat-out doesn't handle right now).
You could probably apply that to 8.1.4 as well if you wanted to; it
should be fine for just loading the database.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Jim Nasby | 2006-05-25 20:55:25 | Re: How to mesure transaction rate in Postgres |
Previous Message | Alvaro Herrera | 2006-05-25 20:43:19 | Re: pg_clog questions |