Re: Declarative partitioning - another take - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: Declarative partitioning - another take
Date
Msg-id CAFjFpRftDTD+Fv3gHhOm9sas8sS=8U+F4cAw=d11QayYjRjuoA@mail.gmail.com
Whole thread Raw
In response to Re: Declarative partitioning - another take  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Declarative partitioning - another take
List pgsql-hackers



+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

pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Why we lost Uber as a user
Next
From: Gerdan Santos
Date:
Subject: Re: psql: tab completion for \l