21. Status Quo
Currently we allow the user to (manually) create arbitrary nested tables with arbitrary constraints and then the planner tries to detect at
run-time which child tables are candidates for the query. See PostgreSQL Partitioning for details. There are some 3rd party plugins that simplify
the (manual) task/triggers, etc. see bottom of this page.
Today, at create time you create a master table, children that inherit from it (and how they are partitioned), separate indices for each child table,
and create an insert trigger so that new rows are inserted to the appropriate (child) table (and/or more aggressive measures, such as allowing
updates to the partitioned key [by default, updates to rows' partitioned key leave them in the same partition, possibly in error], dynamically
allocating new child tables [be careful with race conditions], etc. see the various blogs out there).