Re: Avoiding deeply nested AND/OR trees in the parser - Mailing list pgsql-hackers
| From | Ashutosh Bapat |
|---|---|
| Subject | Re: Avoiding deeply nested AND/OR trees in the parser |
| Date | |
| Msg-id | CAFjFpRev1S8mMmtuXBR03gp60JryY9UN-ysmntJZSC+4ZwLqsw@mail.gmail.com Whole thread Raw |
| In response to | Re: Avoiding deeply nested AND/OR trees in the parser (Tom Lane <tgl@sss.pgh.pa.us>) |
| List | pgsql-hackers |
On Thu, Feb 27, 2014 at 8:51 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Really if we wanted to fixOh, I'd forgotten about that thread. I never particularly liked the patch
>> 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@mail.gmail.com
> http://www.postgresql.org/message-id/flat/CAFj8pRDd9QTyoY0cbPoODR-hfj1xaMBuxWOxAZg0kyVtVaunkw@mail.gmail.com
as presented: like Robert, I thought it far too complicated. My
inclination would just be to tweak the parser enough so that a simple list
of ANDs or ORs (ie, a left-deep raw parse tree) gets flattened.
The most likely bet for making that happen in an uncomplicated way would
be to alter gram.y's processing: if we had the productions for AND/OR
notice whether their left inputs were already AND/OR clauses, they could
extend the argument lists instead of building nested clauses. The reason
the proposed patch is so complicated is it's trying to avoid recursing
while handling a fundamentally recursive data structure, and that's just
the hard way to do it.
We do need to look at whether there are any implications for ruleutils
and other places, though.
ruleutils should be fine. See code below in ruleutils.c
6615 case AND_EXPR:
6616 if (!PRETTY_PAREN(context))
6617 appendStringInfoChar(buf, '(');
6618 get_rule_expr_paren(first_arg, context,
6619 false, node);
6620 while (arg)
6621 {
6622 appendStringInfoString(buf, " AND ");
6623 get_rule_expr_paren((Node *) lfirst(arg), context,
6624 false, node);
6625 arg = lnext(arg);
6626 }
6627 if (!PRETTY_PAREN(context))
6628 appendStringInfoChar(buf, ')');
6629 break;
6615 case AND_EXPR:
6616 if (!PRETTY_PAREN(context))
6617 appendStringInfoChar(buf, '(');
6618 get_rule_expr_paren(first_arg, context,
6619 false, node);
6620 while (arg)
6621 {
6622 appendStringInfoString(buf, " AND ");
6623 get_rule_expr_paren((Node *) lfirst(arg), context,
6624 false, node);
6625 arg = lnext(arg);
6626 }
6627 if (!PRETTY_PAREN(context))
6628 appendStringInfoChar(buf, ')');
6629 break;
Similar code exists for OR_EXPR.
Within the planner, I have seen the quals are always implicitly ANDed lists, where all ANDs are put into a single list. May be same with OR.
As a side note, the code blocks for AND_EXPR and OR_EXPR are almost same except words "AND" and "OR". So there is some chance to get rid of some code duplication here.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
pgsql-hackers by date: