Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> writes:
> My PATCH-1 which make them in the third group forcibly
> classified as 'parent' instead of 'child' as before therefore
> makes 'broken' ec member?
If you marked child entries as non-child, then yes, it's broken.
The definition of a regular EC member is that it's always equal to any
other regular member of that EC, in any row that's had all available WHERE
filter constraints applied to it. This cannot be true for child members
because those are only valid in a subset of rows. Consider
SELECT * FROM t1, (SELECT y FROM t2 UNION ALL SELECT 0 AS y FROM t3) ss
WHERE t1.x = ss.y
We will put t1.x and ss.y into an EC, where ss.y is a variable of the
appendrel representing the union. Then we'll put t2.y and constant 0
into the EC as child members. It would be incorrect to deduce "t1.x = 0"
from this --- while that *is* a valid constraint for join rows arising
from rows out of t3, it's incorrect for rows arising from rows out of t2,
so it's not universally valid.
Basically the point here is that deductions involving child EC members
are one-way. You can use them to generate constraints to apply to a
scan of the associated appendrel member, but not to generate constraints
that would apply to other relations in the query.
In a situation where you're considering "grandchild" elements, both those
and the original children have to be marked as children, because all of
them represent only subsets of rows of the appendrel.
regards, tom lane
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: