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.sontakke@enterprisedb.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
