Unix Technical Forum

pg_dump index creation order

This is a discussion on pg_dump index creation order within the Pgsql Performance forums, part of the PostgreSQL category; --> I'm watching a long, painfully slow 60GB load from pg_dump (8.1.2), and noticing it's jumping back and forth from ...


Go Back   Unix Technical Forum > Database Server Software > PostgreSQL > Pgsql Performance

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #1 (permalink)  
Old 04-19-2008, 08:44 AM
Ed L.
 
Posts: n/a
Default pg_dump index creation order

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...

Ed

---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #2 (permalink)  
Old 04-19-2008, 08:44 AM
Ed L.
 
Posts: n/a
Default Re: pg_dump index creation order

On Saturday May 6 2006 7:15 pm, 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...


And would same idea work for ordering of constraint adding...?

Ed

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #3 (permalink)  
Old 04-19-2008, 08:44 AM
Jim C. Nasby
 
Posts: n/a
Default Re: pg_dump index creation order

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@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 2: Don't 'kill -9' the postmaster

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On
Forum Jump


All times are GMT. The time now is 04:50 AM.


Powered by vBulletin® Version 3.6.5
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO 3.2.0
www.UnixAdminTalk.com