From: | "Steinar H(dot) Gunderson" <sgunderson(at)bigfoot(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: simple join uses indexes, very slow |
Date: | 2006-03-28 16:29:08 |
Message-ID: | 20060328162908.GB26539@uio.no |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tue, Mar 28, 2006 at 10:18:25AM -0600, Dave Dutcher wrote:
>> "parameters_idx" btree (run, opset_num, step_num, opset,
> opset_ver,
>> step, step_ver, name, split, wafers)
>> "parameters_opset_idx" btree (opset, step, name)
>> "parameters_step_idx" btree (step, name)
> Have you tried creating some different indexes on parameters? I don't
> know if it should matter or not, but I would try some indexes like:
>
> (run, opset_num) //Without all the other columns
> (opset_num, run) //Backwards
> (opset_num)
An index on (A,B,C) can be used for a query on (A,B) or (A), so it doesn't
really matter. It isn't usable for a query on (B), (C) or (B,C), though. (The
index rows will get bigger, of course, so you'll need more I/O if you want to
scan large parts of it, but I guess that's beside the point.)
/* Steinar */
--
Homepage: http://www.sesse.net/
From | Date | Subject | |
---|---|---|---|
Next Message | Marcos | 2006-03-28 16:55:28 | Re: Decide between Postgresql and Mysql (help of |
Previous Message | Markus Schaber | 2006-03-28 16:18:44 | Re: Massive Inserts Strategies |