Re: Avoiding deeply nested AND/OR trees in the parser

On Tue, Feb 25, 2014 at 01:15:09PM -0500, Tom Lane wrote:
> Over in
> http://www.postgresql.org/message-id/BAY176-W382A9DE827EBC8E602B7BBC5860@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=_wg(at)mail(dot)gmail(dot)com
http://www.postgresql.org/message-id/flat/CAFj8pRDd9QTyoY0cbPoODR-hfj1xaMBuxWOxAZg0kyVtVaunkw(at)mail(dot)gmail(dot)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