Re: Processing long AND/OR lists

On 6 June 2013 16:13, Gurjeet Singh <gurjeet(at)singh(dot)im> wrote:
> On Mon, May 27, 2013 at 10:32 AM, Christopher Browne <cbbrowne(at)gmail(dot)com>
> wrote:
>>
>> On Mon, May 27, 2013 at 1:42 AM, Gurjeet Singh <gurjeet(at)singh(dot)im> wrote:
>>>
>>>
>>>>
>>>> Joking about "640K" aside, it doesn't seem reasonable to expect a truly
>>>> enormous query as is generated by the broken forms of this logic to turn out
>>>> happily. I'd rather fix Slony (as done in the above patch).
>>>
>>>
>>> Yes, by all means, fix the application, but that doesn't preclude the
>>> argument that the database should be a bit more smarter and efficient,
>>> especially if it is easy to do.
>>
>>
>> Agreed, it seems like a fine idea to have the database support such
>> queries, as this eases coping with applications that might be more difficult
>> to get fixed.
>
>
> Seeing no more objections to it, I am going to add this patch to the
> commitfest. Attached is updated patch against latest master; it's the same
> as the previous version, except that that the patch now includes a fix for
> the failing test case as well.

I'm amazed such lisp-isms still exist, but hey.

This patch seems good, but it begs the question as to whether the
representation is the best one for later use.

When we consider expression cost we need to sort all peer expressions
at same level. Doing that on a left deep tree seems like hard work, so
shouldn't we be starting with a more bushy tree to make the sorting
happen more easily?

There's a few related transforms as well, such as I'd suggest we make
IN() lists and ORd conditions identical in both directions so that
expression proofs work more comprehensively.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services