Alexander Kuzmenkov writes:
> In create_mergejoin_plan:
> * implied inner ordering is then "ORDER BY x, y, x", but the pathkey
> * drops the second sort by x as redundant, and this code must cope.
> -- should this read "the pathkey machinery drops"?
I changed that and improved some othe
Ah, I understand now. We can lie to the executor about the order,
because when we are moving based on the second outer column, we have a
stretch of equal values in the inner column, so we can consider them to
be sorted whatever way we need.
The patch applies cleanly, make check-world passes.
some already-used pathkey */
! ipathkey = NULL;
! ipeclass = NULL;
foreach(l2, innerpathkeys)
{
ipathkey = (PathKey *) lfirst(l2);
ipeclass = ipathkey->pk_eclass;
if (ieclass == ipeclass)
break;
}
! if (l2 == NULL)
elog(ERROR, "inne
El 22/02/18 a las 21:03, Tom Lane escribió:
The third possibility is to decide that create_mergejoin_plan is being
overly paranoid and it's okay to extract merge details from a "redundant"
path key even though it specifies the opposite sort order from what the
current merge clause seems to need.
I wrote:
> The third possibility is to decide that create_mergejoin_plan is being
> overly paranoid and it's okay to extract merge details from a "redundant"
> path key even though it specifies the opposite sort order from what the
> current merge clause seems to need. This is scary at first glanc
Alexander Kuzmenkov writes:
> explain select * from j1_tbl full join (select * from j2_tbl order by
> j2_tbl.i desc, j2_tbl.k) j2_tbl on j1_tbl.i = j2_tbl.i and j1_tbl.i =
> j2_tbl.k;
> ERROR: left and right pathkeys do not match in mergejoin
Nice example. There are several pl
join (select * from j2_tbl order by
j2_tbl.i desc, j2_tbl.k) j2_tbl on j1_tbl.i = j2_tbl.i and j1_tbl.i =
j2_tbl.k;
ERROR: left and right pathkeys do not match in mergejoin
```
It can be reproduced on the latest 9.6, 10 and devel versions.
Basically, j2_tbl is used as the outer relation in merge
