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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
Cc: noah(at)leadboat(dot)com, peter_e(at)gmx(dot)net, robertmhaas(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: UNION ALL on partitioned tables won't use indices.
Date: 2013-11-26 15:46:48
Message-ID: 7496.1385480808@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-11-26 16:22:39 Re: Suggestion: Issue warning when calling SET TRANSACTION outside transaction block
Previous Message Merlin Moncure 2013-11-26 15:37:14 Re: psql shows line number