Re: Caching a partition index's parent OID in the relcache?

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)