Re: Declarative partitioning - another take

On Wed, Oct 5, 2016 at 7:20 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Tue, Oct 4, 2016 at 4:02 AM, Amit Langote
> <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>> [ latest patch set ]
>
> Reviewing 0003:
>
>
> 5. I wonder how well this handles multi-column partition keys. You've
> just got one Datum flag and one is-finite flag per partition, but I
> wonder if you don't need to track is-finite on a per-column basis, so
> that you could partition on (a, b) and have the first partition go up
> to (10, 10), the second to (10, infinity), the third to (20, 10), the
> fourth to (20, infinity), and the last to (infinity, infinity). FWIW,
> Oracle supports this sort of thing, so perhaps we should, too. On a
> related note, I'm not sure it's going to work to treat a composite
> partition key as a record type. The user may want to specify a
> separate opfamily and collation for each column, not just inherit
> whatever the record behavior is. I'm not sure if that's what you are
> doing, but the relcache structures don't seem adapted to storing one
> Datum per partitioning column per partition, but rather just one Datum
> per partition, and I'm not sure that's going to work very well.
>

@@ -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?

--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com