Re: Index/Foreign Key Question

From: Stephan Szabo <sszabo(at)megazone(dot)bigpanda(dot)com>
To: David Busby <busby(at)pnts(dot)com>
Cc: PgSQL Performance ML <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Index/Foreign Key Question
Date: 2003-10-11 00:23:31
Message-ID: 20031010171953.B18529@megazone.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-performance

On Fri, 10 Oct 2003, David Busby wrote:

> ----- Original Message -----
> From: "Ron Johnson"
> > On Fri, 2003-10-10 at 16:04, David Busby wrote:
> > > List,
> > > I'm creating this multi company POS database.
> > > My inventory table looks like (all items are unique):
> > >
> > > id,category_id,invoice_id,x,y,z,gid,uid
> > >
> > > I have a primary key on id, and then an foreign keys on category_id and
> > > invoice_id.
> > > GID is the group ID of the company, UID is the companies user, they are
> also
> > > connected via foreign key to the respective tables. My question is
> this: Do
> > > I need to create more indexes on this table when inventory selects look
> like
> > >
> > > select * from inventory where
> > > category_id = 1 and invoice_id is null and gid = 2
> > >
> > > So where would the indexes need to be placed? Or since I have the FK
> setup
> > > are the indexes already in place? I expect to soon have >500K items in
> the
> > > inventory table and don't want it to slow down. I'll have the same type
> of
> > > issue with clients, invoices, purchase_orders and perhaps more
> >
> > I'd make a multi-segment (non-unique?) index on:
> > GID
> > CATEGORY_ID
> > INVOICE_ID
> >
>
> So the multi column index would be better than the three individual indexes?

For the query in question, yes. However, you probably want a category_id
index and an invoice_id index if you are going to change the related
tables because the (gid, category_id, invoice_id) isn't good enough for
the foreign key checks (and the fk columns aren't automatically indexed
because it can easily become a pessimization depending on the workload
that's being done).

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Christopher Browne 2003-10-11 00:52:29 Re: Redhat RPMs
Previous Message Greg Stark 2003-10-10 23:56:39 Re: log_duration and \timing times repeatably much higher than "Total runtime" from explain analyze

Browse pgsql-performance by date

  From Date Subject
Next Message Bruce Momjian 2003-10-11 01:49:05 Re: go for a script! / ex: PostgreSQL vs. MySQL
Previous Message Sean Chittenden 2003-10-10 22:59:24 Re: go for a script! / ex: PostgreSQL vs. MySQL