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. -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql