Re: Tuple-routing for certain partitioned tables not working as expected

On 2017/08/30 9:13, Amit Langote wrote:
> On 2017/08/29 20:18, Etsuro Fujita wrote:
>> On 2017/08/25 22:26, Robert Haas wrote:
>>> On Wed, Aug 23, 2017 at 4:55 AM, Etsuro Fujita
>>> <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>>>> Agreed, but I'd vote for fixing this in v10 as proposed; I agree that just
>>>> ripping the CheckValidResultRel checks out entirely is not a good idea,
>>>> but
>>>> that seems OK to me at least as a fix just for v10.
>>>
>>> I'm still not on-board with having this be the one case where we don't
>>> do CheckValidResultRel.  If we want to still call it but pass down
>>> some additional information that can selectively skip certain checks,
>>> I could probably live with that.
>>
>> Another idea would be to not do CheckValidResultRel for partitions in
>> ExecSetupPartitionTupleRouting; instead, do that the first time the
>> partition is chosen by ExecFindPartition, and if successfully checked,
>> initialize the partition's ResultRelInfo and other stuff.  (We could skip
>> this after the first time by checking whether we already have a valid
>> ResultRelInfo for the chosen partition.)  That could allow us to not only
>> call CheckValidResultRel the way it is, but avoid initializing useless
>> partitions for which tuples aren't routed at all.
>
> I too have thought about the idea of lazy initialization of the partition
> ResultRelInfos. I think it would be a good idea, but definitely something
> for PG 11.

Agreed. Here is a patch to skip the CheckValidResultRel checks for a
target table if it's a foreign partition to perform tuple-routing for,
as proposed by Robert.

Best regards,
Etsuro Fujita