From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Tuple-routing for certain partitioned tables not working as expected |
Date: | 2017-08-30 00:13:16 |
Message-ID: | 15210b32-d065-4320-72bb-2548f999195c@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
Thanks,
Amit
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2017-08-30 00:19:47 | Re: error-handling in ReorderBufferCommit() seems somewhat broken |
Previous Message | Tomas Vondra | 2017-08-30 00:11:10 | Re: error-handling in ReorderBufferCommit() seems somewhat broken |