Hi, On 2026-03-23 17:54:13 -0400, Melanie Plageman wrote: > I've made some significant changes to 0006 and realized I need some > help. 0006 tracks what relations are modified by a query. This new > version (v44) uses relation oids instead of rt indexes to handle cases > where the same relation appears more than once in the range table > (e.g. INSERT INTO foo SELECT * FROM foo; foo appears twice). It > computes modifiedRelOids (a list of relation OIDs modified by the > query) in the planner and stores them in the PlannedStmt. There is one > big issue I'm not sure how to solve:
I'm not entirely sure this is something we need to catch and therefore not sure that modifiedRelOids is worth the trouble over just having the RT indexes. > For queries like INSERT INTO ptable SELECT * FROM ptable, where ptable > is a partitioned table, though we scan ptable, we don't know when > executing that scan that we will then modify ptable with the insert. But does that matter? If such a query inserts a meaningful amount of rows it's going to insert into different pages than the ones you selected from? > In my patch, I've added find_all_inheritors() when populating > modifiedRelOids, but I realize this probably isn't acceptable to add > to planner from a performance perspective. Agreed. Greetings, Andres Freund
