On Wed, 6 Aug 2003, Tom Lane wrote:
> Sebastien Lemieux <[EMAIL PROTECTED]> 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 pla
On Wed, 6 Aug 2003, Tom Lane wrote:
> "scott.marlowe" <[EMAIL PROTECTED]> 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
Hi,
I'm running on Redhat 7.2 with postgresql 7.3.2 and I have two schema in
the same database 'db' and 'db_dev'. Both contain a set of >20 tables for
a total of less than 50 Mb of data each (on the order of 50k rows in
total). Once in a while (often these days!), I need to synchronize the
dev
Sebastien Lemieux <[EMAIL PROTECTED]> 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 colu
On Wed, 6 Aug 2003, Sebastien Lemieux wrote:
> On Wed, 6 Aug 2003, Tom Lane wrote:
>
> > Sebastien Lemieux <[EMAIL PROTECTED]> 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 h
> >> 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
On Wed, 6 Aug 2003, Tom Lane wrote:
> Sebastien Lemieux <[EMAIL PROTECTED]> 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 pla
Stephan Szabo <[EMAIL PROTECTED]> writes:
> 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.
Good point. We put that in in 7.3.3,
"scott.marlowe" <[EMAIL PROTECTED]> 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 index
Sebastien Lemieux <[EMAIL PROTECTED]> writes:
> On Wed, 6 Aug 2003, Tom Lane wrote:
>> 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
e them
afterwards.
-Nick
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Sebastien
> Lemieux
> Sent: Wednesday, August 06, 2003 1:56 PM
> To: Postgresql-performance
> Subject: [PERFORM] How to efficiently duplicate a whole schema?
>
11 matches
Mail list logo
