Re: How to efficiently duplicate a whole schema?

From: Sebastien Lemieux <slemieux(at)elitra(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Postgresql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: How to efficiently duplicate a whole schema?
Date: 2003-08-07 15:04:40
Message-ID: Pine.LNX.4.33.0308071053080.13718-100000@moebius.elitra.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance


> >> The idea here is to make sure that the planner's statistics reflect the
> >> "full" state of the table, not the "empty" state. Otherwise it may pick
> >> plans for the foreign key checks that are optimized for small tables.
>
> > I added the 'analyze' but without any noticable gain in speed. I can't
> > use 'truncate' since I need to 'set constraints all deferred'.
>
> What are you using, exactly?

What I want to do:

let t be the list of tables

for t in tables:
delete from db_dev.t;

for t in tables:
insert into db_dev.t (...) select ... from db.t;

Some of my foreign keys are creating references loops in my schema, thus
there is no correct order to do the deletes and inserts so that the
constraints are satisfied at all time. I have to enclose those two loops
in a 'set constraints all deferred' to avoid complaints from the
constraints.

I tried dropping the indexes first, doing the transfer and recreating the
indexes: no gain. So computing the indexes doesn't take significant time.

I then tried removing all the foreign keys constraints, replacing delete
by truncate and it now runs in about 25 seconds. Downside is that I lose
the foreign keys integrity verification, but because of this reference
loop in my schema it has caused me more problem than it has avoided until
now. So I can live with that!

Thanks all!

--
Sebastien Lemieux
Bioinformatics, post-doc
Elitra-canada

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message scott.marlowe 2003-08-07 16:15:20 Re: PostgreSQL performance problem -> tuning
Previous Message Richard Huxton 2003-08-07 14:52:48 Re: PostgreSQL performance problem -> tuning