Re: Crash in 9.4 Beta when partially collapsing left outer joins

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: lists(at)benjamindsmith(dot)com, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Crash in 9.4 Beta when partially collapsing left outer joins
Date: 2014-09-10 00:19:56
Message-ID: CAB7nPqRSRDF4d+gQQ2RhxgY2oaZd6QsBRfM2Ebms4r52syJh4g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Tue, Sep 9, 2014 at 10:25 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
>> The logic for nested OR is correct by reading it, hence why not simply
>> removing the assertion failing? The attached patch 1 does so.
>
> The reason for the assert is that there should never be an OR directly
> underneath an OR in the planner after eval_const_expressions has flattened
> such cases. Evidently commit f343a88 failed to preserve AND/OR flatness
> in some cases :-(. That code should be taught to do so, rather than
> lobotomizing this assertion. Lack of flatness causes optimization
> inefficiencies, which is why we don't want to just allow it.
Ah, OK, I just saw your commit. so the trick is to add the arguments
of subclause in case of an OR clause found to have a correct
flattening here... Thanks!
--
Michael

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message David Boreham 2014-09-10 00:31:43 Re: Async IO HTTP server frontend for PostgreSQL
Previous Message Alban Hertroys 2014-09-09 21:46:19 Re: Convincing STABLE functions to run once