Re: On partitioning

On 12/2/14, 9:43 PM, Amit Langote wrote:
>> >What is an overflow partition and why do we want that?
>> >
> That would be a default partition. That is, where the tuples that don't belong elsewhere (other defined partitions)
go.VALUES clause of the definition for such a partition would look like:
 
>
> (a range partition) ... VALUES LESS THAN MAXVALUE
> (a list partition) ... VALUES DEFAULT
>
> There has been discussion about whether there shouldn't be such a place for tuples to go. That is, it should generate
anerror if a tuple can't go anywhere (or support auto-creating a new one like in interval partitioning?)
 

If we are going to do this, should the data just go into the parent? That's what would happen today.

FWIW, I think an overflow would be useful, but there should be a way to (dis|en)able it.

>> >What are you going to do if the partitioning key has two columns of
>> >different data types?
>> >
> Sorry, this totally eluded me. Perhaps, the 'values' needs some more thought. They are one of the most crucial
elementsof the scheme.
 
>
> I wonder if your suggestion of pg_node_tree plays well here. This then could be a list of CONSTs or some such... And
Iam thinking it's a concern only for range partitions, no? (that is, a multicolumn partition key)
 
>
> I think partkind switches the interpretation of the field as appropriate. Am I missing something? By the way, I had
mentionedwe could have two values fields each for range and list partition kind.
 

The more SQL way would be records (composite types). That would make catalog inspection a LOT easier and presumably
makeit easier to change the partitioning key (I'm assuming ALTER TYPE cascades to stored data). Records are stored
internallyas tuples; not sure if that would be faster than a List of Consts or a pg_node_tree. Nodes would
theoreticallyallow using things other than Consts, but I suspect that would be a bad idea.
 

Something else to consider... our user-space support for ranges is now rangetypes, so perhaps that's what we should use
forrange partitioning. The up-side (which would be a double-edged sword) is that you could leave holes in your
partitioningmap. Note that in the multi-key case we could still have a record of rangetypes.
 
-- 
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com