The --auto-partition option is retained in order to support parent/child tables created with inheritance. It is not used when working with parent/child tables created with autopartitioning. Using --auto-partition instructs the Aster Loader Tool to automatically send each row to the right child table during loading. Each row is directed to a table according to the check constraints you have set up on the child tables.
For example, if you partition your data into daily child tables based on the contents of a timestamp column, each ultimate child table in your schema will have a CHECK constraint that specifies what value of timestamp may be loaded into that child table. When you load data, the autopartitioning feature will route each row to the appropriate child table, based on its timestamp value.
Use autopartitioning like this:
-
Set up the parent-child table schema in your database. On each ultimate child table, write a CHECK constraint that specifies what data may be loaded into that child table.
Aster Database does not detect overlapping constraints on peer child tables. As a result, the correct placement of a row during loading can be indeterminate.Workaround: Take care that the constraints you define do not create overlapping logical partitions. A simple mistake would be to set up range constraints like this:
CHECK ( ymdh BETWEEN '2005-07-01' AND '2005-08-01' ); CHECK ( ymdh BETWEEN '2005-08-01' AND '2005-09-01' );
In this example, it is not clear in which partition the ymdh value '2005-08-01' resides.
-
Prepare your data for loading:
- Your data input file can contain data values that will end up in many different child tables.
- To handle rows that do not fit your partitioning scheme, you can rely on the standard error logging feature of the Aster Loader Tool (see Error Logging) or create a check constraint that will catch rows that you do not want to include in your partitions.
- Run the Aster Loader Tool with the -a or --auto-partition flag.