> It seems what's happening here is that dspam is submitting a=20
> query with many thousands of elements in the IN clause. In=20
> the parser, we transform "foo IN (a, b, c)" into "foo =3D a OR=20
> foo =3D b OR foo =3D c", and then recurse for each element of the=20
> OR expression and eventually run out of stack space. (Note=20
> that this will actually be worse in HEAD, since a refactoring=20
> I applied will mean we consume two stack frames for each
> expression.)
>=20
> A workaround would be to increase PostgreSQL's stack size.
>=20
> Perhaps it would be worth considering representing IN lists=20
> as a distinct expression type, at least in the parser. Then the
> transformExpr() code would look like:
Just like I showed earlier on large IN () lists are useless....
Instead I use the UNNEST function I posted earlier (see http://archives.pos=
tgresql.org/pgsql-hackers/2004-11/msg00327.php) like so:
Select id from table inner join unnest(array[1,2,3,4,...]) as d(id) using(i=
d);
Not only does it not crash the backend,. But it also proved to be faster, t=
ho admittedly not much.
... John
