Hello, On 2026-Jul-17, Ayush Tiwari wrote:
> While poking at INSERT ... ON CONFLICT on partitioned tables, > get_partition_ancestors() kept showing up in profiles, it scans > pg_inherits once per hierarchy level, and ExecInitPartitionInfo() calls > it once per leaf-partition index while sorting out arbiter indexes. > There's already an XXX in that loop wondering about a syscache "or some > other way to cache". Yeah. We didn't measure the actual performance impact of that code (see commit e6d6e32f4240) but it's obviously not great. > I tried the "other way": keep the immediate parent OID on the relcache > entry (a lazily-filled rd_partparent), then use the existing walker above > that. This avoids repeatedly scanning the leaf link and eliminates the > pg_inherits scan entirely for the common one-level hierarchy. Patch > attached (fairly small). Hmm. Why not cache the entire list of ancestors instead of just the immediate one? You could have a union that's either a single OID (for the most common case where there's only one ancestor), or a pointer to an array of an arbitrary number of ancestors. With such a system, you only have to scan pg_inherits for a relation once per invalidation, regardless of the number of ancestors. (Looking at pahole's output for RelationData it's obvious that nobody cares too much about how much memory that struct takes.) -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "Hay dos momentos en la vida de un hombre en los que no debería especular: cuando puede permitírselo y cuando no puede" (Mark Twain)
