Re: Declarative partitioning - another take

> +relid_is_partition(Oid relid)
> +{
> + return SearchSysCacheExists1(PARTRELID, ObjectIdGetDatum(relid));
> +}
>
> This is used in a lot of places, and the overhead of checking it in
> all of those places is not necessarily nil. Syscache lookups aren't
> free. What if we didn't create a new catalog for this and instead
> just added a relpartitionbound attribute to pg_class? It seems a bit
> silly to have a whole extra catalog to store one extra column...
>
>
>

It looks like in most of the places where this function is called it's
using relid_is_partition(RelationGetRelid(rel)). Instead probably we should
check existence of rd_partdesc or rd_partkey within Relation() and make
sure that those members are always set for a partitioned table. That will
avoid cache lookup and may give better performance.

That brings up another question. Can we have rd_partdesc non null and
rd_partkey null or vice-versa. If not, should we club those into a single
structure like Partition (similar to Relation)?

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company