JORGE MALDONADO wrote
> And so on. What I see is that it is not a good decision to set a key for
> every possibility because it will have an impact on performance due to
> index maintenance. What would be a good way to define indexes in a case
> like this?
For your specific case, and also more generally, you will define multiple
indexes with a single column within each. PostgreSQL is able to fairly
efficiently scan multiple indexes and then combine them to find records that
exist on both (or other logical combinations).
Multi-key indexes can be advantageous in, for instance, composite primary
key definitions but in this kind of star-schema setup simply have each
foreign key and whatever other searching fields you require maintain their
own individual index.
David J.
P.S.
Arguably, having a separate column for each kind of person is a poor design
at face value - though not uncommon. Whether it is going to bite you in the
future is unknown but depending on whether a single person can hold multiple
roles or if you need to add new roles in the future maintenance and querying
this table for summary information may become more difficult. At the same
time basic data entry and modelling to some degree is easier since this
model is simpler.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Criteria-to-define-indexes-tp5765334p5765336.html
Sent from the PostgreSQL - sql mailing list archive at Nabble.com.
