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

On 2017/08/30 17:20, Etsuro Fujita wrote:
> 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.

I'll add this to the open items list for v10.

Best regards,
Etsuro Fujita