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.ets...@lab.ntt.co.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
