From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Joseph Shraibman <jks(at)selectacast(dot)net> |
Cc: | "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: max_expr_depth |
Date: | 2001-06-19 01:38:41 |
Message-ID: | 9498.992914721@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Joseph Shraibman <jks(at)selectacast(dot)net> writes:
> I recently tried to do a big update with postgres 7.1.2. The update was
> something like
> UPDATE table SET status = 2 WHERE id IN (a few thousand entries) AND
> status = 1;
> and I got:
> ERROR: Expression too complex: nesting depth exceeds max_expr_depth =
> 10000
How many is "a few thousand"? About 10000 by any chance? That
"IN (a, b, ...)" will expand to "((id = a) OR (id = b) OR ...)"
which would set off the expression-too-complex detector right about
10000 ORs, if I'm not mistaken.
You could crank up the max_expr_depth SET variable if you are so
inclined, but frankly performance of this query is going to suck
anyway. I'd recommend sticking the target id values into a temp
table that you can join against, instead.
As for why we have an expression-too-complex check, it's because
mysql's crashme test used to provoke a stack overflow crash...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Joseph Shraibman | 2001-06-19 02:00:41 | Re: max_expr_depth |
Previous Message | Dave Cramer | 2001-06-19 01:35:28 | Error: RelationBuildTriggers: 2 record(s) not found for rel customerinfo |