To: Madison Kelly <linux@alteeve.com>
Cc: pgsql-performance@postgresql.org,
	Bruno Wolff III <bruno@wolff.to>
Subject: Re: Index ot being used 
In-reply-to: <42ADD8DC.1000001@alteeve.com> 
References: <1825.216.209.137.1.1118419819.squirrel@mail.alteeve.com>
	<20050610155535.GO8451@tobias.nordicbet.com>
	<42AC42CB.8050703@alteeve.com> <24636.1118591783@sss.pgh.pa.us>
	<42ACBC95.9020404@alteeve.com> <20050613030001.GB17491@wolff.to>
	<20050613031317.GA18988@wolff.to> <42AD008D.4080600@alteeve.com>
	<20050613035346.GA20703@wolff.to> <42AD0B94.9090508@alteeve.com>
	<20050613132852.GA31142@wolff.to>
	<42ADC77B.7000007@alteeve.com> <22127.1118686403@sss.pgh.pa.us>
	<42ADD8DC.1000001@alteeve.com>
Comments: In-reply-to Madison Kelly <linux@alteeve.com>
	message dated "Mon, 13 Jun 2005 15:05:00 -0400"
Date: Mon, 13 Jun 2005 17:00:04 -0400
Message-ID: <3643.1118696404@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Madison Kelly <linux@alteeve.com> writes:
>    So the index obiously provides a major performance boost! I just need 
> to figure out how to tell the planner how to use it...

Simple division shows that the planner's cost estimate ratio between the
seqscan and the indexscan (11956.84 vs 83171.78) is off by a factor of
more than 8 compared to reality (2018.996 vs 1700.459).  Also the cost of
the sort seems to be drastically underestimated.

I suspect this may be a combination of random_page_cost being too high
(since your test case, at least, is no doubt fully cached in RAM) and
cpu_operator_cost being too low.  I'm wondering if text comparisons
are really slow on your machine --- possibly due to strcoll being
inefficient in the locale you are using, which you didn't say.  That
would account for both the seqscan being slower than expected and the
sort taking a long time.

It'd be interesting to look at the actual runtimes of this seqscan vs
one that is doing a simple integer comparison over the same number of
rows (and, preferably, returning about the same number of rows as this).

			regards, tom lane