Should this table be partitioned? - Adds Complexity - Adds adminstration cost - Number of rows - Types of queries - Data growth
Inheritance does not automatically propagate data from INSERT or COPY commands to other tables in the inheritance hierarchy
It may not be good idea to set this parameter for all queries in system, as not all queries require this feature.
Modifying a Trigger function requires no special locking.
Modifying a Trigger function requires no special locking.
Partition keys are not supposed to be updated. However in that case, we need to delete from child and do insert on base table.
Now() is stable function. STABLE indicates that within a single table scan the function will consistently return the same result for the same argument values, but that its result could change across SQL statements. This is the appropriate selection for functions whose results depend on database lookups, parameter variables (such as the current time zone), etc. Also note that the current_timestamp family of functions qualify as stable, since their values do not change within a transaction.
A table can inherit from more than one parent table, in which case it has the union of the columns defined by the parent tables. Any columns declared in the child table's definition are added to these. If the same column name appears in multiple parent tables, or in both a parent table and the child's definition, then these columns are "merged" so that there is only one such column in the child table. To be merged, columns must have the same data types, else an error is raised. The merged column will have copies of all the check constraints coming from any one of the column definitions it came from, and will be marked not-null if any of them are.
When checking the foreign key, child tables are not considered. You can work around it using additional table indyvidual_pks (indyvidual_pk integer primary key) with all primary keys from both parent and child, which will be maintained using triggers (very simple — insert to indyvidual_pks on insert, delete from it on delete, update it on update, if it changes indyvidual_pk). Then you point foreign keys to this additional table instead of a child. There'll be some small performance hit, but only when adding/deleting rows.
Race condition among maintenance and partitioning trigger. management trigger - creates a new partition, updates the partitioning trigger because of the new partition, etc partitioning trigger - redirects the row into an appropriate partition