On Sat, 13 Apr 2002, Tom Lane wrote:
> Stephan Szabo <sszabo@megazone23.bigpanda.com> writes:
> > On Sat, 13 Apr 2002, Nigel J. Andrews wrote:
> >> I should have mentioned that I'm doing the copy in to the table in a
> >> transaction block with all constraints deferred. That should mean it's only at
> >> the commit stage that foreign key will be checked right?
>
> > With the definition shown, I believe your constraint is not deferrable so
> > setting the constraint mode to deferred won't help. In any case it'd still
> > need to be saving the information on the triggers to run.
>
> In any case the RI trigger firings will be postponed till end of query.
> I suspect that the memory growth is due to the list of pending trigger
> firings. The advice to add the REFERENCES constraint after you've
> loaded the table seems good to me.
>
> Another possibility is that there's some memory leak associated with the
> txtidx data type; I dunno how thoroughly that type has been tested...
I believe I have seen large memory footprints at other times and I haven't used
the txtidx type before. However, I will also do a test loading into a table
with just the standard types. If it turns out to be associated with the new
column I'll sort out who to email and probably also report on here just so
people can get 'closure'.
I'll do the test of loading the table without the foreign ket set also, of
course.
Thanks for the quick replys folks, don't you people ever go home?
--
Nigel J. Andrews
Director
---
Logictree Systems Limited
Computer Consultants
