Hello!
After splitting the the job into smaller pieces (e.g. 18x 1Mrow) the backend process now seems to release the memory
aftereach subjob. Therefore the trigger queue seems to be a good candidate. Until now this queue was unknown to me.
Perhaps a note in the docu of COPY FROM and in the section "13.4.2 Use COPY FROM" within "Performance Tips" would
preventother people like me doing such bad things.
Many thanks for the fast help.
Andreas Heiduk
Stephan Szabo <sszabo@megazone.bigpanda.com> schrieb am 24.08.04 19:25:56:
>
>
> On Tue, 24 Aug 2004, PostgreSQL Bugs List wrote:
>
> > I'm trying to COPY ~18Mrows into a table which has a foreign key to another
> > table. Memory and swap are exhausted and finaly the postgres.log says:
>
> This is very possibly the space taken up by the trigger queue (which
> cannot currently spill out to disk). If you load a smaller number of rows
> does the space go up and then down after the copy ends?
_______________________________________________________________
SMS schreiben mit WEB.DE FreeMail - einfach, schnell und
kostenguenstig. Jetzt gleich testen! http://f.web.de/?mc=021192
