On Fri, Jun 12, 2020 at 9:22 PM Ashutosh Bapat <ashutosh.bapat.oss@gmail.com> wrote: > On Wed, Jun 3, 2020 at 12:44 PM Amit Langote <amitlangote09@gmail.com> wrote: > > Are you saying that the planner should take into account the state of > > the cursor specified in WHERE CURRENT OF to determine which of the > > tables to scan for the UPDATE? Note that neither partition pruning > > nor constraint exclusion know that CurrentOfExpr can possibly allow to > > exclude children of the UPDATE target. > > Yes. But it may not be possible to know the value of current of at the > time of planning since that need not be a plan time constant. This > pruning has to happen at run time.
Good point about not doing anything at planning time.
I wonder if it wouldn't be okay to simply make execCurrentOf() return false if it can't find either a row mark or a Scan node in the cursor matching the table being updated/deleted from, instead of giving an error message? I mean what do we gain by erroring out here instead of simply not doing anything? Now, it would be nicer if we could do so only if the table being updated/deleted from is a child table, but it seems pretty inconvenient to tell that from the bottom of a plan tree from where execCurrentOf() is called.
A safe guard from a bug where current of is set to wrong table or something. Quite rare bug but if we can fix the problem itself removing a safe guard doesn't seem wise.
The other option would be to have some bespoke "pruning" logic in, say, ExecInitModifyTable() that fetches the current active table from the cursor and processes only the matching child result relation.
looks better if that works and I don't see a reason why it won't work.
Or maybe wait until we have run-time pruning for ModifyTable, because the result relation code restructuring required for that will also be something we'd need for this.
I don't see much difference in the final plan with either options.