Re: Patch for automating partitions in PostgreSQL 8.4 Beta 2

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)."

- 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 :)

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

- 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.

Great work all in all!

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