From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
---|---|
To: | "Ed L(dot)" <pgsql(at)bluepolka(dot)net> |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: pg_dump index creation order |
Date: | 2006-05-07 17:08:10 |
Message-ID: | 20060507170810.GL99570@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Sat, May 06, 2006 at 07:15:55PM -0600, Ed L. wrote:
> I'm watching a long, painfully slow 60GB load from pg_dump
> (8.1.2), and noticing it's jumping back and forth from different
> tables. I assume this is the index creation order showing up.
>
> Would it make more sense to have pg_dump dump indexes grouped by
> the table? That way, if a table got loaded into cache for one
> index creation, it might still be there for the immediatly
> following index creations on the same table...
It might for smaller tables that will fit in cache, but it depends on
how much memory is used for sorting. In fact, I think it would be best
to add the indexes immediately after loading the table with data.
This won't help with adding indexes on large tables though, unless
the indexes were created simultaneously, and even that might not be a
win.
It would be a win to add some constraints at the same time, but RI can't
be added until all tables are indexed.
--
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 | kah_hang_ang | 2006-05-08 08:47:44 | extremely slow when execute select/delete for certain tables only... |
Previous Message | Ed L. | 2006-05-07 03:09:20 | Re: pg_dump index creation order |