On Tue, Feb 25, 2014 at 01:15:09PM -0500, Tom Lane wrote: > Over in > http://www.postgresql.org/message-id/bay176-w382a9de827ebc8e602b7bbc5...@phx.gbl > there's a complaint about getting "stack depth limit exceeded" from a > query of the form > > select count(*) from gui_die_summary where (x_coord, y_coord) in > ((25,5),(41,13),(25,7),(28,3),(25,8),(34,7),(26,6),(21,10), ...); > > when there's a few thousand pairs in the IN list. The reason for this > is that transformAExprIn() generates a tree of nested OR expressions, > and then recursion in assign_collations_walker() runs out of stack space.
> Really if we wanted to fix > this issue we'd need to hack up transformAExprAnd/transformAExprOr so that > they recognized nested ANDs/ORs and flattened them on the spot. This > might not be a bad idea, but it's starting to look like more than a quick > hack patch. Reminds me of this work: http://www.postgresql.org/message-id/flat/CABwTF4XJKN1smMjHv_O-QzTpokqSjHBouMWVw-E8kyb2bC=_...@mail.gmail.com http://www.postgresql.org/message-id/flat/cafj8prdd9qtyoy0cbpoodr-hfj1xambuxwoxazg0kyvtvau...@mail.gmail.com > Does this seem worth pursuing, or shall we leave it alone? +1 for fixing. Extrapolating from your figure of 20s and 20 GiB for a million coordinate pairs, we'd have tolerable performance at 20000 pairs instead of just failing as we do today. That's a nice win all by itself. -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
