Date: Thu, 6 Dec 2018 04:57:26 -0300
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: Justin Pryzby <pryzby@telsasoft.com>,
	Sanyo Moura <sanyo.moura@tatic.net>, jeff.janes@gmail.com,
	David Rowley <david.rowley@2ndquadrant.com>,
	Robert Haas <robertmhaas@gmail.com>,
	Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>,
	pgsql-performance@lists.postgresql.org,
	Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Query with high planning time at version 11.1 compared versions
 10.5 and 11.0
Message-ID: <20181206075726.pig32e6thltb56hr@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <8db4eca8-6e76-70ff-f934-e0228a1cc298@lab.ntt.co.jp>
User-Agent: NeoMutt/20180716
Precedence: bulk

On 2018-Dec-06, Amit Langote wrote:

> The partitionwise join related
> changes in PG 11 moved the add_child_rel_equivalences call in
> set_append_rel_size such that child EC members would be added even before
> checking if the child rel is dummy, but for a reason named in the comment
> above the call:
> 
>    ... Even if this child is
>  * deemed dummy, it may fall on nullable side in a child-join, which
>  * in turn may participate in a MergeAppend, where we will need the
>  * EquivalenceClass data structures.
> 
> However, I think we can skip adding the dummy child EC members here  and
> instead make it a responsibility of partitionwise join code in joinrels.c
> to add the needed EC members.  Attached a patch to show what I mean, which
> passes the tests and gives this planning time:

Robert, Ashutosh, any comments on this?  I'm unfamiliar with the
partitionwise join code.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services