Bruno Wolff III wrote:
I think deferred triggers can also use a lot of memory.
I do indeed have several columns with REFERENCES x DEFERRABLE INITIALLY
DEFERRED...
Next time I run the procedure, I will try dropping the foreign key
constraints first.
Incidently, would be nice if Postgres had some
Stephan Szabo wrote:
Explain output would also be useful. I would wonder if it's a problem
with a hash that misestimated the necessary size; you might see if
analyzing the tables involved changes its behavior.
I executed ANALYZE just before running the problematic statement. Will
post the output
On Fri, Feb 04, 2005 at 05:59:26 -0800,
Stephan Szabo <[EMAIL PROTECTED]> wrote:
> On Fri, 4 Feb 2005, Eric Jain wrote:
>
> > I'm trying to fill a table with several million rows that are obtained
> > directly from a complex query.
> >
> > For whatever reason, Postgres at one point starts using
On Fri, 4 Feb 2005, Eric Jain wrote:
> I'm trying to fill a table with several million rows that are obtained
> directly from a complex query.
>
> For whatever reason, Postgres at one point starts using several
> gigabytes of memory, which eventually slows down the system until it no
> longer resp
I'm trying to fill a table with several million rows that are obtained
directly from a complex query.
For whatever reason, Postgres at one point starts using several
gigabytes of memory, which eventually slows down the system until it no
longer responds.
At first I assumed I had unintentionall
