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
