From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: simple join uses indexes, very slow |
Date: | 2006-03-28 17:30:47 |
Message-ID: | 20060328173047.GN75181@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tue, Mar 28, 2006 at 06:29:08PM +0200, Steinar H. Gunderson wrote:
> 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.)
Note that given how statistics currenly work, there are many situations
where the planner will refuse to use a multi-column index. This probably
won't change until there's some concept of multi-column statistics, at
least for multi-column indexes.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Jim C. Nasby | 2006-03-28 17:32:13 | Re: Slow performance on Windows .NET and OleDb |
Previous Message | Jim C. Nasby | 2006-03-28 17:26:35 | Re: count(*) performance |