Re: UNION ALL on partitioned tables won't use indices. - Mailing list pgsql-hackers

From Noah Misch
Subject Re: UNION ALL on partitioned tables won't use indices.
Date
Msg-id 20140228150650.GA3375027@tornado.leadboat.com
Whole thread Raw
In response to Re: UNION ALL on partitioned tables won't use indices.  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: UNION ALL on partitioned tables won't use indices.  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
List pgsql-hackers
On Fri, Feb 28, 2014 at 02:35:50PM +0900, Kyotaro HORIGUCHI wrote:
> At Thu, 27 Feb 2014 21:53:52 -0500, Noah Misch wrote
> > On Thu, Feb 27, 2014 at 05:33:47PM -0500, Tom Lane wrote:
> > > I wonder whether we should consider adding a pass to flatten any nested
> > > appendrels after we're done creating them all.
> > 
> > We did consider that upthread.  It's a valid option, but I remain more
> > inclined to teach pull_up_subqueries() to preserve flatness just like
> > expand_inherited_tables() will.
> 
> Yes, the old dumped version of typ2 patch did so. It flattened
> appendrel tree for the query prpoerly. Let me hear the reson you
> prefer to do so.

Having reviewed my upthread reasoning for preferring one of those two
approaches over the other, it's a weak preference.  They have similar runtime
costs.  Putting the logic with the code that creates appendrels reduces the
number of code sites one must examine to reason about possible plan
structures.  We might not flatten RTE_RELATION appendrel parents exactly the
same way we flatten RTE_SUBQUERY appendrel parents.  I would tend to leave
inh=true for the former, for reasons explained in my notes on v7, but set
inh=false for the latter to save needless work.  On the other hand, a
flattening pass is less code overall and brings an attractive
uniformity-by-default to the area.

-- 
Noah Misch
EnterpriseDB                                 http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Karol Trzcionka
Date:
Subject: Re: [pgsql-advocacy] GSoC 2014 - mentors, students and admins
Next
From: Amit Kapila
Date:
Subject: Re: Patch: show relation and tuple infos of a lock to acquire