Re: Partitioning: issues/ideas (Was: Re: On partitioning)

On 20-01-2015 AM 10:48, Amit Langote wrote:
> On 17-01-2015 AM 02:34, Robert Haas wrote:
>> On Wed, Jan 14, 2015 at 9:07 PM, Amit Langote
>> <Langote_Amit_f8@lab.ntt.co.jp> wrote:
>>> * It is desirable to treat partitions as pg_class relations with perhaps
>>> a new relkind(s). We may want to choose an implementation where only the
>>> lowest level relations in a partitioning hierarchy have storage; those
>>> at the upper layers are mere placeholder relations though of course with
>>> associated constraints determined by partitioning criteria (with
>>> appropriate metadata entered into the additional catalogs).
>>
>> I think the storage-less parents need a new relkind precisely to
>> denote that they have no storage; I am not convinced that there's any
>> reason to change the relkind for the leaf nodes.  But that's been
>> proposed, so evidently someone thinks there's a reason to do it.
>>
> 
> Again, this remains partly tied to decisions we make regarding catalog
> structure.
> 
> I am not sure but wouldn't we ever need to tell from a pg_class entry
> that a leaf relation has partition bounds associated with it? One reason
> I can see that we may not need it is that we would rather use
> relispartitioned of a non-leaf relation to trigger finding all its
> partitions and their associated bounds; we don't need to know (or
> reserve a field for) that a relation has partition bounds associated
> with it. The bounds can be stored in pg_partition indexed by relid.
> Maybe relkind is not the right field for this anyway.
> 
> With that said, would we be comfortable with putting partition key into
> pg_class (maybe as a pg_node_tree also encapsulating opclass) so that if
> relispartitioned, also look for relpartkey?
> 

This paints a picture that our leaf relations would be plain old
relations. They are almost similar in all respects (how they are
planned, modified, maintained, ...). They just have an additional
property that the values they can contain are restricted by, say,
pg_partition.values; but it doesn't concern how they are planned.
Planning related changes are confined to upper layers of the hierarchy
instead. Kinda like saying instead of doing
relation_excluded_by_constraints(childrel), we'd instead say
prune_useless_partitions(&partitionedrel) possibly at some other site
than its counterpart. Guess that illustrates the point.

I am not sure again if we want to limit access to individual partitions
unless via some special syntax, then what that means for the above. We
have been discussing that. Such access limiting could (only) be
facilitated by a new relkind.

On the other hand, the non-leaf relations are slightly new kind of
relations in that they do not have storage (they could have a tablespace
which would be the default tablespace for its underlying partitions).
Obviously they do not have indexes pointing at them. Because they are
further partitioned, they are differently planned - most probably Append
with partition-pruning (almost like Append with constraint-exclusion but
supposedly quicker because of the explicit access to partition
definitions and perhaps execution-time). INSERT/COPY on these involve
routing tuple to the appropriate leaf relation.

Not surprisingly, this is almost similar to the picture that Alvaro had
presented modulo some differences.

Thanks,
Amit