> It seems what's happening here is that dspam is submitting a > query with many thousands of elements in the IN clause. In > the parser, we transform "foo IN (a, b, c)" into "foo = a OR > foo = b OR foo = c", and then recurse for each element of the > OR expression and eventually run out of stack space. (Note > that this will actually be worse in HEAD, since a refactoring > I applied will mean we consume two stack frames for each > expression.) > > A workaround would be to increase PostgreSQL's stack size. > > Perhaps it would be worth considering representing IN lists > 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.postgresql.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(id); Not only does it not crash the backend,. But it also proved to be faster, tho admittedly not much. ... John ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
