Re: Declarative partitioning - another take
| От | Ashutosh Bapat |
|---|---|
| Тема | Re: Declarative partitioning - another take |
| Дата | |
| Msg-id | CAFjFpRftDTD+Fv3gHhOm9sas8sS=8U+F4cAw=d11QayYjRjuoA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Declarative partitioning - another take (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: Declarative partitioning - another take
|
| Список | 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
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company
В списке pgsql-hackers по дате отправления: