Re: [HACKERS] Tuple-routing for certain partitioned tables notworking as expected
От | Amit Langote |
---|---|
Тема | Re: [HACKERS] Tuple-routing for certain partitioned tables notworking as expected |
Дата | |
Msg-id | 15210b32-d065-4320-72bb-2548f999195c@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] Tuple-routing for certain partitioned tables notworking as expected (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>) |
Ответы |
Re: [HACKERS] Tuple-routing for certain partitioned tables notworking as expected
|
Список | 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.etsuro@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. Thanks, Amit
В списке pgsql-hackers по дате отправления: