Re: UNION ALL on partitioned tables won't use indices.

Hello, 

> No hurry.

Thanks.

> > > > The attached two patches are rebased to current 9.4dev HEAD and
> > > > make check at the topmost directory and src/test/isolation are
> > > > passed without error. One bug was found and fixed on the way. It
> > > > was an assertion failure caused by probably unexpected type
> > > > conversion introduced by collapse_appendrels() which leads
> > > > implicit whole-row cast from some valid reltype to invalid
> > > > reltype (0) into adjust_appendrel_attrs_mutator().
> > > 
> > > What query demonstrated this bug in the previous type 2/3 patches?
> 
> I would still like to know the answer to the above question.

Ouch! Sorry but I couldn't replay the bug just now, please wait
for a while.

> It's true that each AppendRelInfo is initially created that way, but they need
> not remain so simple.  You can assume ctx->child_appinfo->translated_vars
> contains only these Var nodes, but parent_appinfo->translated_vars may contain
> arbitrary expressions.  (I think the pullup_replace_vars() call at
> prepjointree.c:954 is where an AppendRelInfo can get non-Var expressions.)

Itself is not a problem.

My patch doesn't replace parent's sole Var at top-level with the
corresponding node in child, it repaces any Var node in parent's
expressions in translated_vars with the corresponding node in
child. So expressions in FROM clauses of union's-operand queries
can adequately modifies expressions made in prepjointree. The
query like follows returns correct result with this patch. As I
mentioned before, I think the other stuffs than Var pullup would
be done in adjust_appendrel_attrs separately.

|  SELECT (a + 1) as x, (b * 3) as y FROM p1
|  UNION ALL
|  SELECT (a * 2), (b / 5) FROM p2 ORDER BY x LIMIT 10;


> > So all we should do to collapse nested appendrels is simplly
> > connecting each RTEs directly to the root (most ancient?) RTE in
> > the relationship, resolving Vars like above, as seen in patched
> > expand_inherited_rtentry.
> > 
> > # If translated_vars are generated always in the way shown above,
> > # using tree walker might be no use..
> > 
> > This can be done apart from all other stuffs compensating
> > translation skew done in adjust_appendrel_attrs. I believe they
> > are in orthogonal relationship.
> 
> Here is a test case that provokes an assertion failure under the patch; I
> believe the cause is oversimplification in transvars_merge_mutator():
> 
> create table parent (a int, b int);
> create table child () inherits (parent);
> select parent from parent union all select parent from parent;

Wow. Ok, I'm pretty convinced that you're right. I'll dig it on.

> While poking at that test case, I noticed that the following test emits three
> rows on HEAD and wrongly emits four rows with the patch:
> 
> create table parent (a int, b int);
> create table child () inherits (parent);
> insert into parent values (1,10);
> insert into child values (2,20);
> select a, b from parent union all select a, b from child;

Mmm. I had the same result. Please let me have a bit more time.


regards,


-- 
Kyotaro Horiguchi
NTT Open Source Software Center