Re: [HACKERS] Tuple-routing for certain partitioned tables notworking as expected
От | Etsuro Fujita |
---|---|
Тема | Re: [HACKERS] Tuple-routing for certain partitioned tables notworking as expected |
Дата | |
Msg-id | 1f3c3f04-8a0c-f147-2367-b02a6f797002@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: [HACKERS] Tuple-routing for certain partitioned tables notworking as expected (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] Tuple-routing for certain partitioned tables notworking as expected
|
Список | pgsql-hackers |
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. > At some point we've got to stop developing v10 and just let it be what it is. I agree on that point, but ISTM that this is more like a bug. Best regards, Etsuro Fujita
В списке pgsql-hackers по дате отправления: