Re: How to efficiently duplicate a whole schema?

From: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Sebastien Lemieux <slemieux(at)elitra(dot)com>, Postgresql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: How to efficiently duplicate a whole schema?
Date: 2003-08-06 20:00:59
Message-ID: Pine.LNX.4.33.0308061357480.16326-100000@css120.ihs.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Wed, 6 Aug 2003, Tom Lane wrote:

> "scott.marlowe" <scott(dot)marlowe(at)ihs(dot)com> writes:
> > On Wed, 6 Aug 2003, Tom Lane wrote:
> >> 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.)
>
> > Is this one of those things that should spit out a NOTICE when it happens?
> > I.e. when a table is created with a references and uses a different type
> > than the parent, would it be a good idea to issue a "NOTICE: parent and
> > child fields are not of the same type"
>
> I could see doing that for unequal data types, but I'm not sure if it's
> reasonable to do it for lack of index. Usually you won't have created
> the referencing column's index yet when you create the FK constraint,
> so any warning would just be noise. (The referenced column's index *is*
> checked for, since we require it to be unique.)

Sure. I wasn't thinking of the index issue anyway, just the type
mismatch.

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message scott.marlowe 2003-08-06 20:09:14 Re: partitioning for postgresql
Previous Message Tom Lane 2003-08-06 19:29:23 Re: How to efficiently duplicate a whole schema?