Re: Patch for automating partitions in PostgreSQL 8.4 Beta 2

Hi Nikhil,

I am sorry for the late reply. :(

Please find inline my comments.

On Tue, Jun 9, 2009 at 2:54 PM, Nikhil Sontakke <
nikhil(dot)sontakke(at)enterprisedb(dot)com> wrote:

> Hi,
>
>
>>
>> The patch automates table partitioning to support Range and Hash
>> partitions. Please refer to attached readme file for further details.
>>
>> The syntax used conforms to most of the suggestions mentioned in
>> http://archives.postgresql.org/pgsql-hackers/2008-01/msg00413.php,
>> barring the following:
>> -- Specification of partition names is optional. System will be able to
>> generate partition names in such cases.
>> -- Sub partitioning
>>
>
> Some comments based on a brief glance of the patch:
>
> - The logic to execute the partition triggers last still needs some more
> work IMHO. Relying on just the names might not get accepted. I think you
> should pay attention to Andrew Dunstan's suggestion in an earlier mail to
> have tgkind enumerations to generalize the same or discuss it further.
>
> "the scheme should turn tgisconstraint into a multi-valued item (tgkind:
> 'u' = userland, 'c'= constraint, 'p' = partition or some such)."
>

Kedar >> I am working on to turn tgisconstraint into a multi-values item to
categorize user, constraint and partition triggers. In doing so, I am
thinking of adding adding 'PARTITION' keyword to existing syntax to create
partition triggers i.e. CREATE PARTITION TRIGGER ... The partition triggers
would now be identified with the type rather than naming scheme though
naming scheme for partition triggers would still be there.

>
> - Similarly, assigning "of_relname_oid" names to overflow tables also might
> not work. The best way ahead could be to invent a new relkind
> RELKIND_OVERFLOW to handle it. Or maybe we can have a new schema pg_overflow
> to store the overflow relation with the same name (suffixed with _overflow
> to make it clearer) as the parent relation too. The relkind solution might
> be cleaner though. This might need further discussion. In general, it is
> definitely not a bad idea to discuss such sub-problems on the list :)
>

Kedar >> I will look at it once done with catagorizing partition triggers. I
am inclined toward using a new relkind like RELKIND_OVERFLOW.

>
>
> - Am I reading the patch correctly that you do not end up creating indexes
> on the children tables? That is a big problem!

Kedar >> As Srinath K is working on global indexes, the merge of
partitioning and global indexes should be able to extend indexes created on
partitioned table to children as well.

>
>
> - You can remove the remnants of the first patch like the
> MutateColumnRefs() function, for example (I agree this is WIP, but
> unwanted/unused functions unnecessarily add to the size). With large
> patches, the more precise the patch, the better it will be for
> reviewers/readers.

Kedar >> Yeah.

>
>
> Great work all in all!

Kedar >> Thanks! Looking forward to your continued co-operation.

>
>
> Regards,
> Nikhils
> --
> http://www.enterprisedb.com
>