[prev in list] [next in list] [prev in thread] [next in thread] 

List:       postgresql-admin
Subject:    Re: [ADMIN] Restore of pg_dump taking a long time...
From:       Jim Nasby <jnasby () pervasive ! com>
Date:       2006-05-25 20:51:54
Message-ID: 6D7A0D55-3364-4733-B721-90BDC0D252C6 () pervasive ! com
[Download RAW message or body]

On May 24, 2006, at 2:56 PM, Todd A. Cook wrote:

> Tom Lane wrote:
>> "Todd A. Cook" <tcook@blackducksoftware.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@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461



---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
       subscribe-nomail command to majordomo@postgresql.org so that your
       message can get through to the mailing list cleanly
[prev in list] [next in list] [prev in thread] [next in thread]