Re: How to efficiently duplicate a whole schema?

From: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
To: Sebastien Lemieux <slemieux(at)elitra(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Postgresql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: How to efficiently duplicate a whole schema?
Date: 2003-08-06 21:41:43
Message-ID: 20030806143746.J7786-100000@megazone.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, 6 Aug 2003, Sebastien Lemieux wrote:

> On Wed, 6 Aug 2003, Tom Lane wrote:
>
> > Sebastien Lemieux <slemieux(at)elitra(dot)com> writes:
> > > All the time is taken at the commit of both transaction.
> >
> > Sounds like the culprit is foreign-key checks.
> >
> > One obvious question is whether you have your foreign keys set up
> > efficiently in the first place. As a rule, the referenced and
> > referencing columns should have identical datatypes and both should
> > be indexed. (PG will often let you create foreign key constraints
> > that don't meet these rules ... but performance will suffer.)
>
> I've checked and all the foreign keys are setup between 'serial' (the
> primary key of the referenced table) and 'integer not null' (the foreign
> key field). Would that be same type? A couple of my foreign keys are not
> indexed, I'll fix that. The latter seems to do the job, since I can now
> synchronize in about 75 seconds (compared to 30 minutes), which seems good
> enough.

Another thing might be the management of the trigger queue. I don't think
7.3.2 had the optimization for limiting the scans of the queue when you
have lots of deferred triggers. It looks like 7.3.4 may though.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2003-08-06 21:47:36 Re: How to efficiently duplicate a whole schema?
Previous Message Sam Barnett-Cormack 2003-08-06 21:39:52 Re: PostgreSql under Linux