Another thought about this general topic:
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> ...
> Allowed actions on a RELKIND_PARTITION:
> * CREATE INDEX .. ON PARTITION <n> ON TABLE <xyz>
> ...
> Still To Be Designed
> --------------------
> * Are indexes/constraints inherited from the parent rel?
I think one of the key design decisions we have to make is whether
partitions are all constrained to have exactly the same set of indexes.
If we don't insist on that it will greatly complicate planning compared
to what we'll get if we do insist on it, because then the planner will
need to generate a separate customized plan subtree for each partition.
Aside from costing planning time, most likely that would forever prevent
us from pushing some types of intelligence about partitioning into the
executor.
Now, in the current model, it's up to the user what indexes to create
on each partition, and sometimes one might feel that maintaining a
particular index is unnecessary in some partitions. But the flip side
of that is it's awfully easy to screw yourself by forgetting to add
some index when you add a new partition. So I'm not real sure which
approach is superior from a purely user-oriented perspective.
I'm not trying to push one or the other answer right now, just noting
that this is a critical decision.
regards, tom lane