Re: [PERFORM] Foreign key performance - Mailing list pgsql-hackers

From Stephan Szabo
Subject Re: [PERFORM] Foreign key performance
Date
Msg-id 20030419235530.S23637-100000@megazone23.bigpanda.com
Whole thread Raw
In response to Re: [PERFORM] Foreign key performance  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PERFORM] Foreign key performance  (Stephan Szabo <sszabo@megazone23.bigpanda.com>)
List pgsql-hackers
On Sat, 19 Apr 2003, Tom Lane wrote:

> Stephan Szabo <sszabo@megazone23.bigpanda.com> writes:
> > The hack was just the keeping around the list pointer from the last run
> > through (see attached - passed simple fk tests and regression, but there
> > might be problems I don't see).
>
> Shouldn't this patch update the comment in deferredTriggerInvokeEvents
> (c. line 1860 in cvs tip)?

Probably, since the second part of that is basically what this is.  I'll
update and send updated patch tomorrow.

> > Looking at the code, I also wonder if we
> > would get some gain by not allocating the per_tuple_context at the
> > beginning but only when a non-deferred constraint is found since otherwise
> > we're creating and destroying the context and possibly never using it.
>
> I doubt it's worth worrying over.  Creation/destruction of a never-used
> memory context is pretty cheap, I think.

Okay, sounds good enough for me. :)



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: rename/unlink handling for Win32
Next
From: Cadili
Date:
Subject: Re: How to write make rules for shared library and