Re: Restore of pg_dump taking a long time...
От | Jim Nasby |
---|---|
Тема | Re: Restore of pg_dump taking a long time... |
Дата | |
Msg-id | 6D7A0D55-3364-4733-B721-90BDC0D252C6@pervasive.com обсуждение исходный текст |
Ответ на | Re: Restore of pg_dump taking a long time... ("Todd A. Cook" <tcook@blackducksoftware.com>) |
Список | pgsql-admin |
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
В списке pgsql-admin по дате отправления: