pg.ddx.io pgsql-sql@postgresql.org mailing list archive
help / color / mirror / Atom feedCriteria to define indexes
2+ messages / 2 participants
[nested] [flat]
* Criteria to define indexes
@ 2013-07-26 23:10 JORGE MALDONADO <jorgemal1960@gmail.com>
0 siblings, 1 reply; 2+ messages in thread
From: JORGE MALDONADO @ 2013-07-26 23:10 UTC (permalink / raw)
To: pgsql-sql
I have a table with fields as follows:
* sag_id
* sag_header
* sag_comments
* sag_date
* sag_section_id (**)
* sag_artist_id (**)
* sag_author_id (**)
* sag_producer_id (**)
As you can see, fields mark with (**) are identifiers that reference
another table (catalog of sections, catalog of artists, etc). Firstly, I
need an index on "sag_date" because our application has a search option
under this criteria. However, there are also search criterias on
"sag_section", "sag_artist", "sag_author" and "sag_producer" because, for
example, a user may need to get the records of certain artist only.
Furthermore, our application offers a user to select several cominations of
criterias:
* Artist + Author
* Artist + Producer
* Artist + Author + Producer
* Section + Artist.
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?
With respect,
Jorge Maldonado
^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Criteria to define indexes
@ 2013-07-27 00:31 David Johnston <polobo@yahoo.com>
parent: JORGE MALDONADO <jorgemal1960@gmail.com>
0 siblings, 0 replies; 2+ messages in thread
From: David Johnston @ 2013-07-27 00:31 UTC (permalink / raw)
To: pgsql-sql
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
^ permalink raw reply [nested|flat] 2+ messages in thread
end of thread, other threads:[~2013-07-27 00:31 UTC | newest]
Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2013-07-26 23:10 Criteria to define indexes JORGE MALDONADO <jorgemal1960@gmail.com>
2013-07-27 00:31 ` David Johnston <polobo@yahoo.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox