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

From Amit Langote
Subject Re: Declarative partitioning - another take
Date
Msg-id 4567d060-406e-9644-5f3e-41ed054f1bfa@lab.ntt.co.jp
Whole thread Raw
In response to Re: Declarative partitioning - another take  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Declarative partitioning - another take  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On 2016/10/26 17:57, Amit Kapila wrote:
> @@ -123,6 +123,9 @@ typedef struct RelationData
> {
> ..
>   MemoryContext rd_partkeycxt; /* private memory cxt for the below */
>   struct PartitionKeyData *rd_partkey; /* partition key, or NULL */
> + MemoryContext rd_pdcxt; /* private context for partdesc */
> + struct PartitionDescData *rd_partdesc; /* partitions, or NULL */
> + List   *rd_partcheck; /* partition CHECK quals */
> ..
> }
> 
> I think one thing to consider here is the increase in size of relcache
> due to PartitionDescData.  I think it will be quite useful in some of
> the cases like tuple routing.  Isn't it feasible to get it in some
> other way, may be by using relpartbound from pg_class tuple?

Whereas pg_class.relpartbound stores partition bound of the *individual
partitions* in Node form, the above relcache struct is associated with
parent tables; it contains some efficient to use (and fairly compact)
representation of bounds of *all* the partitions of the parent.  Consider
for example, an array of sorted range bounds for range partitioned tables.

Thanks,
Amit





pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: Push down more full joins in postgres_fdw
Next
From: Etsuro Fujita
Date:
Subject: Re: Push down more full joins in postgres_fdw