Amit Langote <amitlangot...@gmail.com> writes: > On Thu, Apr 1, 2021 at 3:12 AM Tom Lane <t...@sss.pgh.pa.us> wrote: >> Amit Langote <amitlangot...@gmail.com> writes: > [ v14-0002-Initialize-result-relation-information-lazily.patch ] >> Needs YA rebase over 86dc90056.
> Done. I spent some time looking this over. There are bits of it we can adopt without too much trouble, but I'm afraid that 0001 (delay FDW BeginDirectModify until the first actual update) is a nonstarter, which makes the main idea of delaying ExecInitResultRelation unworkable. My fear about 0001 is that it will destroy any hope of direct updates on different remote partitions executing with consistent semantics (i.e. compatible snapshots), because some row updates triggered by the local query may have already happened before a given partition gets to start its remote query. Maybe we can work around that, but I do not want to commit a major restructuring that assumes we can dodge this problem when we don't yet even have a fix for cross-partition updates that does rely on the assumption of synchronous startup. In some desultory performance testing here, it seemed like a significant part of the cost is ExecOpenIndices, and I don't see a reason offhand why we could not delay/skip that. I also concur with delaying construction of ri_ChildToRootMap and the partition_tuple_routing data structures, since many queries will never need those at all. > * PartitionTupleRouting.subplan_resultrel_htab is removed in favor > of using ModifyTableState.mt_resultOidHash to look up an UPDATE > result relation by OID. Hmm, that sounds promising too, though I didn't look at the details. Anyway, I think the way to proceed for now is to grab the low-hanging fruit of things that clearly won't change any semantics. But tail end of the dev cycle is no time to be making really fundamental changes in how FDW direct modify works. regards, tom lane