Date: Tue, 28 Mar 2006 18:29:08 +0200
From: "Steinar H. Gunderson" <sgunderson@bigfoot.com>
To: pgsql-performance@postgresql.org
Subject: Re: simple join uses indexes, very slow
Message-ID: <20060328162908.GB26539@uio.no>
Mail-Followup-To: pgsql-performance@postgresql.org
References: <20060327134733.72422d23.gry@ll.mit.edu>
	<00c901c65283$401f14d0$8300a8c0@tridecap.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <00c901c65283$401f14d0$8300a8c0@tridecap.com>
User-Agent: Mutt/1.5.11+cvs20060126

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/