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

On Tue, Sep 05, 2017 at 08:35:13PM +0900, Etsuro Fujita wrote:
> 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.

[Action required within three days. This is a generic notification.]

The above-described topic is currently a PostgreSQL 10 open item. Robert,
since you committed the patch believed to have created it, you own this open
item. If some other commit is more relevant or if this does not belong as a
v10 open item, please let us know. Otherwise, please observe the policy on
open item ownership[1] and send a status update within three calendar days of
this message. Include a date for your subsequent status update. Testers may
discover new open items at any time, and I want to plan to get them all fixed
well in advance of shipping v10. Consequently, I will appreciate your efforts
toward speedy resolution. Thanks.

[1] https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com