Re: review: Non-recursive processing of AND/OR lists

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gurjeet Singh <gurjeet(at)singh(dot)im>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: review: Non-recursive processing of AND/OR lists
Date: 2014-04-25 02:21:17
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Gurjeet Singh <gurjeet(at)singh(dot)im> writes:
> I tried to eliminate the 'pending' list, but I don't see a way around it.
> We need temporary storage somewhere to store the branches encountered on
> the right; in recursion case the call stack was serving that purpose.

I still think we should fix this in the grammar, rather than introducing
complicated logic to try to get rid of the recursion later. For example,
as attached.

The existing A_Expr representation of raw AND/OR nodes isn't conducive to
this, but it's not that hard to change it. The attached patch chooses to
use BoolExpr as both the raw and transformed representation of AND/OR/NOT;
we could alternatively invent some new raw-parsetree node type, but I
don't see any advantage in that.

I continue to think that more thought is needed about downstream
processing. For instance, at least the comment at the head of prepqual.c
is wrong now, and it's worth wondering whether the planner still needs to
worry about AND/OR flattening at all. (It probably does, to deal with
view-flattening cases for example; but it's worth considering whether
anything could be saved if we stopped doing that.)

regards, tom lane

Attachment Content-Type Size
flatten-and-or-in-grammar-1.patch text/x-diff 20.0 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2014-04-25 06:28:55 Re: Composite Datums containing toasted fields are a bad idea(?)
Previous Message Christopher Browne 2014-04-25 01:51:17 Re: UUIDs in core WAS: 9.4 Proposal: Initdb creates a single table